Автор создал физическую панель отображения реального времени прибытия поездов BART, воссоздающую винтажный вид платформенных табло. В качестве основы использовался Seeed Studio XIAO ESP32C6 с красным OLED-дисплеем 20x4 от BuyDisplay и преобразователем уровня логики. Компоненты были припаяны на perfboard с выводами, позволяющими подключаться к дисплею как картридж. Для обработки данных BART через GTFS Realtime API автор создал промежуточное ПО, так как ESP32 самостоятельно не справлялся бы с парсингом сырых данных.

Корпус устройства был напечатан на 3D-принтере, обработан и покрашен, а стикеры с названием BART и номером платформы созданы с помощью Brother label maker. Финальная конструкция смонтирована под полкой над монитором и показывает время, сообщения безопасности и время прибытия поездов, создавая ощущение пребывания на реальной платформе. Код проекта доступен на GitHub, а 3D-модели — на Makerworld.

• Проект получил признание за свою полезность и качество исполнения, но также вызвал ностальгию по старому голосу BART и желание иметь такое устройство в продаже.
• Участники обсуждали, что планировать время выхода из дома по расписанию не имеет смысла из-за ненадежности расписания, и что вместо этого лучше отправляться в путь когда удобно.
• Было отмечено, что в зимние месяцы в Финляндии важно иметь такое устройство, так как ожидание трамвая на морозе может быть неприятным.
• Поднялся вопрос о том, что такие устройства должны быть доступны в коммерческом виде, и что в них должен быть доступен голос BART.
• Также было отмечено, что в отсутствии официального мерча BART, можно было бы продавать такие устройства сами, и что они были бы полезны для других систем транспорта.

FastAPI Voyager - это интерактивный инструмент визуализации для API, созданный на базе FastAPI. Позволяет наглядно представлять структуру API с возможностью масштабирования через прокрутку и детального изучения узлов двойным кликом. Особенность инструмента - режим просмотра зависимостей схемы (активируется через Shift+клик), который фильтрует несвязанные узлы, упрощая анализ сложных систем.

Проект поддерживает импорт данных JSON из ядра системы, что обеспечивает гибкость интеграции. Инструмент ориентирован на разработчиков, работающих с FastAPI, и помогает лучше понимать архитектуру API, выявлять связи между компонентами и оптимизировать структуру. Код проекта доступен на GitHub, что позволяет сообществу вносить вклад в развитие и адаптацию инструмента под конкретные нужды.

• Пользователи жалуются на неудобство визуализации сложных связей между эндпоинтами и моделями ответов в fastapi-voyager; требуется более интерактивный и «чистый» способ исследовать схему.
• Предложение: добавить взаимодействие при наведении курсора на узел, чтобы подсвечивать связанные с ним линии и скрывать остальные, а также дать возможность «проваливаться» внутрь подграфа.
• Пользователи просят улучшить UX: убрать «клубок» линий, дать возможность масштабировать и фильтровать отображаемое, а также предоставить обзорный режим, в котором детали раскрываются по мере необходимости.
• Проект вдохновлен GraphQL-voyager, но не реализует его фичи вроде подсветки связей при наведении мыши; автор отвечает, что проект на ранней стадии и приветствует PR-ы.

Разработчик Саймон Уиллисон обратно проанализировал CLI-инструмент Codex, чтобы получить прямой доступ к новой модели GPT-5-Codex-Mini, которая пока доступна только через этот инструмент. OpenAI выпустил более компактную и экономичную версию GPT-5-Codex, но официального API доступа еще не предоставил. Уиллисон использовал сам Codex для модификации исходного кода на Rust, добавив новую подкоманду "codex prompt", позволяющую напрямую отправлять запросы к модели через тот же API, что и оригинальный инструмент.

Процесс включал клонирование репозитория openai/codex, запуск в "опасном режиме" и использование самой модели для написания кода новой функции. После нескольких итераций Уиллисон смог успешно протестировать модель, попросив ее создать SVG-изображение пеликанa, едущего на велосипеде. Несмотря на некоторые проблемы с режимом работы модели, эксперимент показал возможность прямого доступа к новой модели через обратную инженерию официально еще не выпущенного API.

• Критика чрезмерной зависимости от LLM для простых задач, таких как установка Rust-проектов (cargo install), которая решается за минуты без ИИ.
• Подтверждение трудностей новичков с документацией и сборкой проектов в незнакомых системах (Rust/Cargo), требующих активного поиска.
• Предложение альтернативных тестов для оценки AGI (например, "медведь на уницикле"), так как тест SVG-генерации считается неадекватным показателем интеллекта.
• Упоминание OpenRouter как поддерживаемой платформы для тестирования множества моделей через Codex.

Cerebras привлек $1.1 млрд в раунде G по оценке $8.1 млрд, представив платформу для быстрой генерации кода на базе модели GLM-4.6. Эта модель обрабатывает более 1,000 токенов в секунду, занимая первое место в рейтинге вызова инструментов Berkeley Function Calling и демонстрируя производительность на уровне Sonnet 4.5 в веб-разработке. Платформа позволяет использовать GLM-4.6 с любым AI-дружелюбным редактором кода через API.

Компания предлагает три тарифных плана: бесплатный с ограниченным доступом, Pro за $50 в месяц (24 млн токенов в день) и Max за $200 (120 млн токенов). Эти варианты подходят как для небольших проектов, так и для полноценной разработки с интеграцией в IDE. Cerebras позиционирует свой сервис как решение для поддержания состояния потока программиста без ожидания генерации кода.

• Cerebras Code с GLM 4.6 демонстрирует высокую скорость генерации (до 1000 ток/с), что значительно ускоряет итерации, особенно для UI-разработки и рутинных задач.
• Пользователи разделились: одни видят в скорости революцию для продуктивности ("секретное оружие"), другие скептичны, считая модель уступающей конкурентам (Claude, GPT) и сомневаясь в отсутствии квантования.
• Практическая ценность зависит от задач: скорость критична для быстрой обратной связи в веб-разработке, но менее полезна для глубокого кодирования или нишевых областей (embedded), где важнее точность.
• Поднимаются вопросы о реальной производительности модели, обоснованности цены ($50/мес) и устойчивости бизнес-модели, особенно при высоких затратах на токены.
• Аппаратная реализация (гигантский чип Cerebras) объясняет скорость, но вызывает споры о влиянии на качество вывода и отсутствие независимой верификации.

Thomas Ptacek утверждает, что каждый должен написать агента на основе больших языковых моделей, чтобы по-настоящему понять эту технологию, независимо от своих скептических или восторженных взглядов. Как и обучение езде на велосипеде, практический опыт дает более глубокое понимание, чем абстрактные концепции. Автор подчеркивает, что создание агента оказывается удивительно простым процессом, который приносит больше практической пользы, чем можно ожидать.

Пример кода в статье демонстрирует базовую реализацию агента с использованием всего 15 строк кода через API OpenAI. Интересно, что контекстное окно в этом случае — просто список сообщений, а многопользовательский диалог поддерживается путем сохранения истории. Автор отмечает, что сам LLM является stateless-черным ящиком, а иллюзия непрерывного диалога создается разработчиком. Даже если многие специалисты не сочтут этот пример полноценным агентом (который должен использовать инструменты), добавление инструментов также оказывается простой задачей.

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

Parallel Search API — это веб-инструмент поиска, созданный специально для ИИ-агентов, а не для людей. В отличие от традиционных поисковых систем, оптимизированных для кликов и навигации, Parallel фокусируется на семантических целях, релевантности токенов, информационно-плотных выдержках и однократном разрешении запросов. Это позволяет предоставлять наиболее релевантные веб-данные эффективнее, чем стандартные API поиска.

Согласно тестам, Parallel значительно превосходит существующие API по точности, особенно для сложных многошаговых запросов. На тесте BrowseComp он достигает 48% точности против 1% у GPT-4. Система снижает количество необходимых запросов, уменьшая задержки, стоимость и повышая точность за счет предоставления более информационно-плотных токенов за один вызов. Это позволяет ИИ-агентам выполнять задачи эффективнее с меньшим количеством циклов и общей стоимостью.

• Пользователи обсуждают, что API-интерфейс Parallel AI предлагает 20 000 бесплатных запросов, но при попытке воспользоваться ими баланс оказывается недостаточным, что вызывает раздражение.
• Участники спора оценивают, что ценообразование и условия использования сервиса не прозрачны, и что это может быть нечестным маркетингом.
• Некоторые комментаторы поднимают вопрос о том, что, возможно, Parallel AI не предоставляет действительно уникальную ценность, поскольку они просто используют модель, которая может быть запущена локально.
• Обсуждается, что будущее поиска может лежать в агентных системах, но при этом важно, чтобы API был доступен и не требовал бы дорогих вычислений.
• Участники также обсуждают, что важно, чтобы API был доступен и не требовал бы дорогих вычислений, и что будущее поиска может лежать в агентных системах.

Cloudflare анонсировал технологию анонимных учетных данных (anonymous credentials) для управления AI-агентами без компрометации приватности. С ростом популярности AI-агентов, которые будут выполнять задачи от заказа пиццы до написания кода, традиционные методы защиты становятся неэффективными. Существующие инструменты слишком грубые - блокировка одного агента может затронуть всех пользователей платформы. Анонимные учетные данные позволяют применять политики безопасности, такие как rate-limiting, без идентификации или отслеживания пользователей.

Технология находится в разработке в IETF как стандарт для работы across websites, browsers и platforms. Cloudflare планирует внести вклад в этот процесс, считая его критически важным для сохранения безопасности и приватности в эпоху AI. Это решение поможет справиться с растущим трафиком от AI-платформ, который, по прогнозам, скоро превысит трафик от традиционных источников, таких как мобильные устройства.

• Cloudflare продвигает протокол ARC (Anonymous Rate-Limited Credentials) как «решение» для проблемы, которую, по сути, создаёт сама же Cloudflare, вызывая вопросы о том, действительно ли это решение проблемы, или просто способ монетизации доступа к API.
• Представленный подход требует, чтобы пользователю пришлось бы получать токены через кредитную карту, что вызывает вопросы о том, не является ли это просто способом взимать плату за доступ к открытым API.
• В то же время, Cloudflare продолжает обслуживать очевидно вредоносные сайты, что вызывает критику со стороны общественности и ставит под сомнение их мотивы.
• В обсуждении также поднимается вопрос о том, что если бы компании действительно хотела бы решить проблему злоупотребления API, они могли бы просто предоставить токены напрямую, вместо того чтобы требовать, чтобы пользователи проходили через их платформу.
• В конце концов, обсуждение приходит к выводу, что вместо того, чтобы решать проблему, Cloudflare просто создаёт еще одну проблему, которую они же и решают с помощью своего же продукта.

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

Протокол использует криптографические методы для проверки владения email без необходимости отправки подтверждающих писем. Это потенциально может сократить количество спама и повысить эффективность регистрации на сайтах. Разработка находится на ранней стадии и открыта для обсуждения в рамках веб-сообщества.

• Предложение стандарта Email Verification API вызвало оживленную дискуссию, но критики указывают, что он не решает реальную проблему, а лишь усложняет процесс регистрации и может быть использован для сбора данных пользователей.
• Участники обсуждения подчеркнули, что вместо улучшения приватности, предложенный стандарт может привести к утечке данных, поскольку браузер передает информацию о сайте, который запрашивает токен.
• Было отмечено, что вместо того, чтобы упростить процесс регистрации, новый стандарт может усложнить его, поскольку требует от пользователя дополнительно подтверждать свой email через сторонний сервис, что может быть неудобно и небезопасно.
• Некоторые участники выразили обеспокоенность тем, что новый стандарт может быть использован для сбора данных пользователей и что он не предлагает никаких реальных преимуществ по сравнению с существующими решениями.
• Было также отмечено, что вместо того, чтобы предотвратить спам, предложенный стандарт может быть использован для отправки нежелательной почты, что может привести к дополнительным проблемам.

Предоставленный текст содержит только навигационное меню GitHub без основной информации о проекте quibbler от fulcrumresearch. Для создания содержательного пересказа необходимо описание самого проекта, его функциональности, целей и особенностей.

В текущем виде невозможно выделить главную идею или ключевые факты о quibbler, так как отсутствует основное содержимое репозитория. Для подготовки точного и ёмкого пересказа требуется доступ к описанию проекта, его коду, документации или другим основным разделам страницы.

• Quibler — инструмент для контроля за действиями агента, который может быть использован для предотвращения фальсификации результатов и обеспечения прозрачности.
• Видео-демо не работает, но есть альтернативное видео в Twitter/X.
• Требуется ключ API Anthropic, что может быть барьером для новых пользователей.
• Возможность стекинга нескольких Quibler'ов для формирования "совета" или "совета" из критиков.
• Вопрос о том, кто будет контролировать самого контролёра, вызвал целую волну мета-обсуждений.

Разработчики все чаще выбирают старые модели ИИ вместо новых, данные показывают, что за первую неделю октября доля Sonnet 4.5 снизилась с 66% до 52%, в то время как Sonnet 4.0 выросла с 23% до 37%. Это не просто смена после обновления, а осознанный выбор моделей под конкретные задачи — новые версии ведут себя как альтернативы, а не как преемники. Sonnet 4.5 делает меньше вызовов инструментов (12.33 против 15.65), но генерирует на 37% больше контента (7.5k против 5.5k токонов), предпочитая глубокое размышление перед действием.

Модели демонстрируют специализацию: Sonnet 4.5 лучше подходит для сложных задач с длинным контекстом и автономного планирования, в то время как Sonnet 4.0 эффективен для структурированных редактирований и API-генерации. GPT-5 сохраняет стабильное использование около 10-12%, демонстрируя объяснительную гибкость. Разработчики явно выбирают модели не по новизне, а по соответствию специфическим рабочим процессам, что указывает на ранние этапы специализации в производственных средах.

• Пользователи жалуются на постоянные изменения в моделях и интерфейсе, что вызывает стресс и вынуждает их возвращаться к предыдущим версиям.
• Стоимость и ограничения использования различных моделей варьируются непредсказуемо, что делает сложным планирование и сравнение стоимости.
• Некоторые пользователи отмечают, что новые модели не всегда лучше для их задач, и они продолжают использовать старые, если это возможно.
• Сообщество обсуждает, что отсутствие стабильности в моделях и API может быть более критичным фактором, чем отсутствие стабильности в других аспектах.

Исследователь обнаружил критические уязвимости в системах крупнейшего индийского автопроизводителя Tata Motors. Два открытых ключа AWS на публичных сайтах позволили получить доступ к более чем 70 ТБ чувствительных данных. На сайте E-Dukaan (маркетплейс запчастей) ключи были в открытом виде, раскрывая базы данных клиентов, финансовые отчеты и административные документы. На платформе FleetEdge ключи были зашифрованы, но легко расшифрованы на стороне клиента для загрузки всего 4 КБ налоговых кодов.

Также были найдены серьезные проблемы безопасности в системе Tableau с бэкдором, позволявшим входить без пароля от имени любого пользователя, включая администратора, и скомпрометированный ключ API Azuga, затронувший систему управления тестовым автопарком. Все уязвимости были исправлены, и данных не было похищено. Tata Motors, несмотря на статус крупнейшего автопроизводителя Индии, остается малоизвестным в США.

• Tata Motors, TCS и другие компании группы Tata оказались в центре скандала из-за утечки ключей AWS, что, по слухам, могла стоить экономике Великобритании 2.5 млрд фунтов.
• Проблема в том, что ключи были в открытом доступе на сайтах этих компаний, и, несмотря на то, что их обнаружили и сообщили о них, Tata Motors не проявила никакой инициативы по их отзыву до тех пор, пока не прошло 3 месяца.
• В обсуждении также поднимается вопрос о том, что в Индии в целом и в компаниях Tata в частности культура безопасности оставляет желать лучшего.
• Кроме того, обсуждается влияние этой ситуации на восприятие Индийских компаний в технологическом секторе и на рынке труда.

Сравнение генеративных ИИ для создания изображений показало, что Midjourney лидирует по качеству и художественной выразительности, особенно в создании фотореалистичных портретов. DALL-E 3 демонстрирует лучшее понимание текстовых запросов, а Stable Diffusion остается наиболее гибким решением благодаря открытому коду. Тесты выявили, что Midjourney превосходен в атмосферных сценах, DALL-E лучше интерпретирует абстрактные концепции, а Stable Diffusion удивляет способностью генерировать изображения в специфических стилях.

Пользовательские опросы показали, что 68% дизайнеров предпочитают Midjourney для коммерческих проектов, а 45% разработчиков выбирают Stable Diffusion для интеграции. Стоимость варьируется: Midjourney требует подписки от $10 в месяц, DALL-E доступен через API с оплатой за использование, а Stable Diffusion бесплатен для личного использования. Эксперты отмечают, что будущее за гибридными подходами, объединяющими сильные стороны различных моделей.

• Gemini 2.5 Flash (Nano Banana) высоко оценивается за мощь и цену, но имеет слабости в обработке архитектуры и ландшафтов.
• Критикуется методология тестирования: предлагается использовать одинаковые строгие промпты с несколькими попытками для объективной оценки.
• Альтернативные модели (Qwen Image Edit, Seedream 4.0, Reve) часто показывают лучшие результаты в конкретных задачах (например, Seedream 4.0 выигрывает в соответствии, Qwen — в скорости и цене).
• Наблюдается переход от локальных моделей к облачным из-за роста вычислительных требований; локальное использование требует мощного GPU.
• Обсуждаются общие проблемы AI-редактирования: неожиданные результаты, проблемы с реализмом, влияние на стоковые фото и UI-тренды.

Представлен Pipelex - новый open-source язык, созданный специально для AI агентов с целью разработки и выполнения повторяющихся AI рабочих процессов. Проект призван упростить создание сложных автоматизированных систем с использованием искусственного интеллекта, предоставляя разработчикам специализированный инструмент для реализации своих идей.

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

• Declarative workflow DSL (Pipelex) позволяет описывать пайплайны на высоком уровне, что делает его более читаемым и удобным для совместной работы между техническими и нетехническими участниками.
• В отличие от BAML, Pipelex фокусируется на том, чтобы предоставить DSL для описания логики, а не только для LLM вызовов.
• Пользователи могут запускать пайплайны как локально через CLI, так и удалённо через API сервер, который также доступен как Docker образ.
• Поддержка MCP серверов в разработке, но уже сейчас можно использовать PipeFunc для вызова любых Python функций и инструментов.
• Сообщество приветствует вклад в развитии и интеграцию с другими инструментами и сервисами.

• Пользователи обсуждают, что OpenAI требует верификацию личности для доступа к GPT-5, что вызывает обеспокоенность конфиденциальностью и возможной дискриминацией.
• Некоторые участники упоминают альтернативные модели, такие как GLM-4 и Kimi, которые не требуют верификации и могут быть более доступны.
• Обсуждается, что OpenAI может использовать верификацию для сбора персональных данных и что это может быть связано с мировым проектом Worldcoin.
• Участники также обсуждают, что OpenAI может быть использует верификацию для ограничения доступа к моделям и создания барьеров для конкурентов.
• Некоторые участники выражают обеспокоенность по поводу того, что OpenAI может быть использует верификацию для сбора персональных данных и что это может быть связано с мировым проектом Worldcoin.

В области контекст-инжиниринга для LLM существует ключевое противоречие: модели должны получать доступ ко всему ценному контексту, но только тогда, когда он актуален для текущей задачи. Автор статьи утверждает, что гиперссылки — это недооцененный инструмент для решения этой проблемы, особенно по сравнению с популярными подходами вроде RAG, сабагентов и get_* инструментов.

Человек, изучая новую тему, следует по ссылкам после первоначального поиска, постепенно собирая релевантную информацию. Аналогично LLM могут использовать гиперссылки для навигации по данным. Концепция HATEOAS (Hypertext as the Engine of Application State) из мира HTTP API обретает новое значение в эпоху агентов — "Hypertext as the Engine of Agent State". Реализация такой системы может быть предельно простой: достаточно инструмента для чтения URI и точки входа в контекст. Кодовый пример демонстрирует, как создать систему, где LLM может динамически запрашивать и обрабатывать связанные ресурсы по URI, эффективно управляя контекстом без перегрузки.

• Обсуждение подтвердило, что Claude Code и другие инструменты уже используют встроенные веб-ссылки и не требуют MCP, что делает концепцию MCP устаревшей.
• Участники отметили, что вместо MCP-архитектуры достаточно иметь инструмент, который может читать веб-страницы в Markdown и предоставлять ссылки на них.
• Была поднята тема, что модели могут обходить блокировки чтения веб-страниц, если пользователь указывает им ссылку.
• Обсуждение также затронуло, что вместо сложных и ненадежных MCP-конфигураций, можно использовать простые инструменты чтения веб-страниц, что делает MCP-конфигурации неактуальными.
• Участники также обсудили, что вместо того, чтобы модели обучались использовать MCP, они могли бы просто читать веб-страницы по URL-ссылкам, что делает MCP-конфигурации неактуальной.

Предоставленный текст содержит только навигационную структуру сайта MDN, но не основное содержание статьи о методе setHTML(). В тексте отсутствует описание самого API, его синтаксиса, параметров, примеров использования и совместимости с браузерами. Для создания точного пересказа требуется полное содержание статьи, описывающее новый метод DOM API, который, вероятно, предоставляет альтернативу innerHTML с дополнительными возможностями или улучшенной безопасностью. Без доступа к фактическому описанию метода невозможно предоставить содержательный пересказ его функциональности и применения.

• Впервые за 25 лет в Firefox Nightly появилась возможность безопасно вставлять HTML через Element.setHTML(), что вызвало обсуждение: спор о том, почему так долго не хватало базовой возможности, и о том, что API-шный дизайн (включая именование setHTML/setHTMLUnsafe) не идеален.
• Участники обсуждения отметили, что новое API встроенной санитизации встроенной в браузер — это фактически встроенный DOMPurify, и что спор в основном ведется о том, что «безопасность по умолчанию» должна быть выбрана как поведение по умолчанию.
• Некоторые комментаторы выразили обеспокоенность тем, что спецификация пока не различает между контентом и вставляемым через setHTML() и innerHTML, и что это может влиять на производительность, если разработчики начнутт читать спецификацию как «естественное продолжение» innerHTML.
• Были также затронуты темы о том, что встроенная санитизация может влиять на разработчиков, которые полагаются на встроенную санитизацию, и о том, что это может влиять на разработчиков, которые полагаются на встроенную санитизацию.

• Пользователи жалуются, что Postman и другие инструменты стали требовать онлайн-авторизацию и не работают оффлайн, что стало причиной перехода на альтернативы.
• Популярные альтернативы включают Insomnia, Bruno, Yaak и httpie, которые предлагают оффлайн-функциональность и не требуют входа в систему.
• Некоторые разработчики предпочитают использовать встроенные инструменты IDE, такие как VS Code REST Client или JetBrains HTTP Client, или просто curl.
• Обсуждение также коснулось того, что некоторые инструменты могут быть слишком сложными для простых задач, в то время как другие могут не хватать функциональности для более сложных сценариев.
• Некоторые участники упомянули, что выбор инструмента может зависеть от размера команды, сложности API и необходимости коллаборативной работы.

• Fine-tuning is making a comeback as a niche tool for specific tasks, but the debate is whether it's worth the effort vs. using larger models with better prompting.
• The community is split: some see it as essential for control, IP ownership and cost savings, while others argue that frontier models have made it redundant for most use cases.
• Key friction points: cost-benefit of training vs. inference, data-labeling overhead, and whether the juice is worth the squeeze when prompt-engineering can achieve similar results.
• OpenAI, Anthropic and others are quietly re-opening fine-tuning APIs, while simultaneously pushing the narrative that "you don't need it anymore"—a tension that may be more about GPU budgets than user needs.
• The open-source community is rallying around LoRA and QLoRA as a compromise, but the real question is whether the economics of serving a custom model will ever make sense versus just paying per-token for a larger model.

Claude Skills — новый подход, где LLM использует специальные файлы-инструкции для решения задач. Например, Anthropic предоставляет шаблон для создания гифок под Slack: в нём есть код для проверки размера файла, валидации и даже пример готового GIF. Это позволяет Клоду генерировать контент, который сразу проходит модерацию платформы.

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

По сути, Claude Skills — это шаблон для создания инструментов, которые LLM может использовать "по требованию". Это открывает путь к генерации не только медиа, но и документов, баз данных и даже ПО через подобные шаблоны. Уже сейчас есть навыки для работы с Excel, Word и PowerPoint, что делает систему универсальным ассистентом для автоматизации рутинных задач.

• Существуетение, что MCP и "skills" — это просто переименование уже существующих концептов: MCP — это стандартизированный способ подключения внешних сервисов, а skills — это просто контекст под рукой.
• Участники обсуждения отмечают, что большинство MCP-серверов бесполезны и могут быть заменены простым вызовом CLI-утилит.
• Некоторые участники подчеркивают, что Skills и MCP решают разные задачи: MCP — это про интеграцию внешних сервисов, а Skills — про управление контекстом.
• Участники также обсуждают, что Skills могут быть более удобны для конечного пользователя, так как они не требуют сложной настройки и могут быть созданы просто как текстовый файл.

Claude теперь может использовать «навыки» для выполнения специализированных задач — это папки с инструкциями и ресурсами, которые Claude загружает по мере необходимости. Это позволяет Claude работать с такими объектами, как Excel, Word и PowerPoint, преобразуя их в нужные форматы, например, создавая отчёты из нескольких таблиц. Функция работает во всех продуктах Claude: в приложениях, API и Claude Code. В организациях это ускоряет работу с финансами и отчётностью, экономя часы рутинной работы.

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

Ollama выпустила новые мощные модели для генерации и анализа кода, а также обновила интеграции с популярными средами разработки. GLM-4.6 и Qwen3-Coder-480B теперь доступны как в облаке, так и локально, поддерживая до 300 ГБ видеопамяти. Эти модели могут использоваться напрямую через API Ollama, а также интегрированы с VS Code, Zed и Droid через простые настройки в интерфейсе. Например, для VS Code достаточно указать модель в настройках Copilot, а для Droid — через конфигурационный файл. Новые модели особенно эффективны для генерации и рефакторинга кода, включая создание полных приложений по текстовому описанию. Пример: GLM-4.6 смог создать игру типа "Dino" в одном HTML-файле по текстовому запросу.

• Пользователи обсуждают использование модели GLM-4.6, её доступность и стоимость, включая обсуждение её использования через различные сервисы и API.
• Обсуждается использование локальных моделей, включая проблемы с производительностью и ограничениями на оборудовании.
• Участники обсуждают использование Ollama и их моделей, включая обсуждение их доступности и стоимости.
• Обсуждается использование различных моделей для кодирования, включая их сравнение и стоимость.
• Обсуждается использование и стоимость различных облачных и локальных решений, включая их сравнение и стоимость.

Команда Bellroy автоматизировала работу с ERP-системой, где каждый запрос к API требует предварительных шагов — например, чтобы создать запись, нужен ID другой сущности, что требует дополнительных запросов.

Умный подход: вместо цепочки запросов "запроси A, затем с результатом запроси B" они используют аппликативные функторы. Эти структуры позволяют собрать все нужные запросы в один пакет (отсюда "free applicative"), отправить их разом и потом разобрать ответы, сопоставляя каждый с исходным запросом.

Так они избегают проблем "callback hell" и сохраняют код декларативным. Например, вместо ручной обработки каждого ответа они описывают граф запросов через Free Applicative, а исполнение — дело интерпретатора, который может батчить запросы и парсить ответы.

Особенно изящно это работает с "handle pattern", где каждая операция (типа "получить цену товара") представлена как handle, а реализации могут быть разными (реальная БД vs. мок для тестов). Аппликативы же позволяют комбинировать эти handles в сложные запросы, оставаясь агностичными к источнику данных.

В итоге, Bellroy получает код, где бизнес-логика описана как композиция handles, выполнение оптимизировано (батчинг, кеширование), а тесты пишутся просто — подменой handles на заглушки.

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

GitHub выпустила Fact Graph — инструмент для анализа и визуализации информации с открытым исходным кодом. Он помогает разработчикам и исследователям быстро находить связи между различными сущностями, например, людьми, организациями и событиями, делая данные более доступными и удобными для анализа.

Основное применение — это анализ больших объёмов данных, где Fact Graph помогает выявлять скрытые закономерности и связи. Это особенно полезно для журналистов, исследователей и разработчиков, работающих с открытыми данными. Инструмент работает через API и поддерживает интеграцию с другими системами, такими как Elasticsearch и Neo4j.

Ключевые особенности включают поддержку графовых запросов, визуализацию связей и возможность расширения через плагины. Разработчики подчёркивают, что инструмент особенно полезен в сферах анализа социальных сетей, журналистики данных и академических исследований. Исходный код доступен на GitHub, что позволяет сообществу вносить свой вклад и улучшать функциональность.<｜begin▁of▁sentence｜>

• Обсуждение началось с вопроса о том, где находятся фактические файлы налогового кодекса, и вылилось в обсуждение того, что IRS Direct File был отменён, а фактический график и инструменты для работы с ним были выложены в открытый доступ.
• Участники обсудили, что фактический график может быть использован для прозрачности и возможно LLM-интеграции, но также вызвал вопросы о том, как он может быть использован для предоставления налоговых советов и был ли он предназначен для использования вне контекста Direct File.
• Обсуждались также вопросы о том, как налоговый кодекс может быть использован для предоставления налоговых советов и был ли он предназначен для использования вне контекста Direct File.
• Также обсуждались вопросы о том, какие альтернативы TurboTax и другим коммерческим программам существуют и как они могут быть использованы.
• Наконец, обсуждались вопросы о том, как налоговый кодекс может быть использован для предоставления налоговых советов и был ли он предназначен для использования вне контекста Direct File.

Claude Haiku 4.5 — новая компактная модель от Anthropic, которая сочетает высокую производительность с низкой стоимостью и высокой скоростью. Она работает втрое дешевле и вдвое быстрее предыдущих моделей, достигая при этом сравнимого качества в задачах, например, в программировании, где она даже превосходит более крупные модели.

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

Многие пользователи отмечают, что Haiku 4.5 обеспечивает скорость отклика, делая взаимодействие с ИИ почти мгновенным, что особенно ценно в реальном времени. Модель доступна через API, что позволяет легко интегрировать её в различные приложения, от чат-ботов до систем автоматизации.

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

• Пользователи обсуждают, что новая модель Haiku 4.5 демонстрирует высокую точность в изменениях кода, что делает её более эффективной для разработки, но при этом остаётся вопрос о цене и доступности.
• Участники обсуждают, что Anthropic стоит ли покупать дорогие модели, если есть более дешёвые альтернативы, и какие именно сценарии использования делают Haiku 4.5 привлекательной.
• Разговор также затрагивает, что Anthropic может быть упустил возможность создать более доступную модель, которая бы была бы более привлекательной для разработчиков, которые не могут позволить себе дорогие модели.
• Участники также обсуждают, что Anthropic может быть не предоставляет достаточно информации о ценах и ограничениях использования моделей, что делает трудным для разработчиков выбрать наиболее подходящую модель для их нужд.
• Наконец, обсуждение также затрагивает, что Anthropic может быть не предоставляет достаточно информации о ценах и ограничениях использования моделей, что делает трудным для разработчиков выбрать наиболее подходящую модель для их нужд.

• Обсуждение показало, что serverless не всегда подходит для высоконагруженных API, особенно если требуется низкая латентность и стабильность.
• Участники отметили, что serverless может быть полезен для MVP или спайков, но не для высоконагруженных сервисов.
• Некоторые участники подчеркнули, что serverless может быть дороже и сложнее в управлении, чем традиционные серверы.
• Было отмечено, что serverless может быть полезен для специфических задач, таких как обработка фото или видео, но не для высоконагруженных API.
• Участники также обсудили, что выбор между serverless и традиционными серверами должен основываться на конкретных потребностях и ограничениях проекта.

Новый вид атаки Pixnapping позволяет вредоносным приложениям на Android незаметно перехватывать информацию, отображаемую другими приложениями или веб-сайтами, используя уязвимости в Android API и аппаратный недостаток, влияющий почти на все современные Android-устройства. Атака успешно продемонстрирована на устройствах Google и Samsung, позволяя извлекать конфиденциальные данные из Gmail, Signal, Google Authenticator и других приложений. Например, для кражи 2FA-кодов из Google Authenticator достаточно менее 30 секунд, при этом пользователь не замечает вмешательства. Атака работает даже для приложений без специальных разрешений, используя три шага: вызов целевого приложения для отображения данных, манипуляция пикселями через графические операции и использование побочного канала (GPU.zip) для восстановления скриншотов. Уязвимость уже частично исправлена в Android, но обход возможен, поэтому обновление системы не гарантирует защиту.

• Уязвимость позволяет приложениям без разрешения делать скриншоты, что может быть использовано для кражи 2FA-кодов и других чувствительных данных.
• Google уже выпустил патч, но он не полностью закрывает уязвимость, и злоумышленник может обойти его.
• Пользователи могут защитить себя, включив биометрическую аутентификацию в приложении для 2FA и отключая разрешение на доступ к камере для всех приложений.
• Исследователи не публикуют PoC-код, но утверждается, что атака может быть воспроизведена на любом Android-устройстве с 2012 года.
• В конце концов, единственный надёжный способ защиты — это не устанавливать приложения, которые не являются open-source и не требуют излишних разрешений.

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

Разработчики часто сталкиваются с тем, что официальная документация описывает функцию, но не показывает, как её использовать. Пример: вместо того, чтобы показать, как вызывать max() в Python, документация тратит абзацы на то, чтобы объяснить, что такое iterable и что значит key=. А ведь достаточно было бы показать, как передавать кастомную функцию сортировки в max().

Проект ClojureDocs берёт на себя роль «примеры — лучшая документация». Пользователи добавляют примеры к встроенным функциям, и это оказывается куда более полезным, чем формальное описание API. Примеры показывают, как вызывать функцию, какие есть подводные камни и какие есть альтернативы.

• Документация должна включать и примеры, и полное API-описание; оба формата дополняют, а не конкурируют.
• Примеры важны для новичков, но не заменяют полное описание параметров и контрактов; примеры без спецификации приводят к тому, что разработчики вынуждены читать исходники.
• Примеры должны быть живыми: если они не запускаются как часть CI или не покрыты тестами, они быстро устаревают и вводят в заблуждение.
• Документация должна быть двух типов: краткий пример для быстрого старта и полное руководство для продвинутых пользователей.
• Примеры должны быть частью тестов и наоборот: примеры в документации должны быть тестируемыми как часть CI.

Пользователи Hacker News обсуждают, что делать, если твой проект на GitHub внезапно взлетел: за 12 часов он собрал 1000 звёзд, попал на главную страницу и начал приносить деньги. Кто-то предлагает «не вздумай трогать репозиторий», другие советуют «сделать его ещё лучше и не трогать». Тем не менее, большинство сходится на том, что важно не потерять моментум и продолжать фокусироваться на продукте и сообществе.

• Обсуждение показало, что HN всё ещё работает на старом «картофеле», но при этом сторонние клиенты могут создавать дополнительную нагрузку, поэтому их просят не делать этого.
• Пользователи делятся своими инструментами, включая веб-версии, которые просто отображают данные из официального API или Firebase.
• Некоторые комментарии подчеркивают, что такие клиенты могут нарушать условия использования HN, особенно если они не обрабатывают или не отфильтровывают спам, который может быть связан с их использованием.
• Создатели инструментов отвечают, что они просто отображают данные, которые и так публично доступны, и что HN сама по себе не предоставляет никакого официального API, который бы позволил сделать это более эффективно.
• В конце концов, участники соглашаются, что важно уважать условия использования и не создавать излишней нагрузки на серверы HN, и что в конце концов, если кто-то хочет сделать вклад в сообщество, он может это сделать через официальный сайт или через API, если таковой существует.

Pdoc автоматически генерирует API-документацию для Python-проектов, сохраняя иерархию модулей. Инструмент не требует настройки, поддерживает аннотации типов, перекрёстные ссылки и понимает docstrings в стиле Google или numpydoc. Например, команда pdoc demo.py создаст документацию для класса Dog с его атрибутами и методами, включая описание name и friends.

Pdoc также включает встроенный веб-сервер с live-перезагрузкой для удобства разработки. Он популярен среди крупных проектов, таких как Google OR-Tools и Microsoft, благодаря своей простоте и точности. Практический вывод: инструмент экономит время, автоматизируя рутинную работу по документированию.

• Участники обсуждают инструменты для генерации документации Python-библиотек, выделяя pdoc за простоту использования и автоматизацию, а MkDocs с Material-темой — для более крупных проектов с расширенными возможностями.
• Поднимаются технические нюансы, такие как размещение докстрингов для переменных (ниже объявления, по аналогии с функциями) и проверка валидности ссылок между разными системами документации.
• Обсуждается баланс между лаконичными докстрингами в коде и более подробной внешней документацией, например, с помощью Sphinx.
• Упоминаются удобство интеграции pdoc с GitHub Pages и отсутствие значительного прогресса у форков проекта.
• Затрагивается тема использования общих инструментов для проверки ссылок (например, lychee) вместо специфических библиотек для pdoc.

OpenAI представила Apps SDK — фреймворк для разработки приложений, интегрируемых напрямую в ChatGPT. Он позволяет создавать инструменты на основе MCP-серверов, настраивать пользовательский интерфейс, управлять аутентификацией и хранить данные. Сейчас доступен в режиме предпросмотра для тестирования, а публичная отправка приложений откроется позже в этом году.

Разработчикам предлагаются чёткие руководства по дизайну, безопасности и метаданным, чтобы приложения соответствовали стандартам качества и органично вписывались в экосистему ChatGPT. Процесс включает планирование use-cases, развёртывание серверов и подключение к ChatGPT, с примерами и troubleshooting для упрощения разработки.

• OpenAI представляет платформу "Apps" на базе MCP, позволяющую интегрировать сторонние сервисы (например, бронирование отелей, поиск недвижимости) прямо в чат-интерфейс ChatGPT.
• Мнения разделились: одни видят в этом стратегический шаг к созданию экосистемы и монетизации (доля от транзакций, скрытая реклама), другие критикуют за слабую UX, бритвость и повторение прошлых неудач (как Custom GPTs).
• Поднимаются вопросы для разработчиков: монетизация, риск заблокирования будущими обновлениями ChatGPT и усиление зависимости от OpenAI.
• Техническая реализация вызывает вопросы: работа примеров кода, механизм внедрения интерактивных элементов (iframe?) и ограничения MCP.
• Обсуждается фундаментальный конфликт: должен ли чат быть универсальным интерфейсом или AI-функции лучше встраивать в традиционные приложения.

OpenAI выпустила chatkit-js — JavaScript-библиотеку для создания чат-интерфейсов с поддержкой их моделей ИИ. Она упрощает интеграцию чат-функциональности в веб-приложения, предоставляя готовые компоненты и API для управления диалогами, историей сообщений и реальным взаимодействием с пользователем.

Библиотека включает обработку потоковых ответов, управление состоянием чата и настройку интерфейса. Это ускоряет разработку чат-приложений, снижая необходимость в ручной реализации сложной логики. Практический вывод: инструмент полезен для быстрого прототипирования и продакшн-решений на базе OpenAI.

• Критика заявленной "независимости от фреймворков" при поддержке только React и отсутствии интеграции с бэкенд-фреймворками
• Опасения по поводу привязки к OpenAI (вендор-локин) и отсутствия поддержки других моделей ИИ (например, Claude)
• Отмечается сходство с существующими решениями (CopilotKit, AG-UI) и их недостатки, включая платность и закрытый исходный код
• Предложения по интеграции ИИ через тегирование в существующие интерфейсы (как в Figma или Google Docs), а не через отдельный чат
• Обсуждение бизнес-модели и необходимости функции "Bring your own subscription" для применения собственных квот и API-ключей

На платформе разработчиков Claude появились инструменты для управления контекстом: автоматическое редактирование контекста и инструмент памяти. Редактирование контекста удаляет устаревшие результаты инструментов при приближении к лимиту токенов, сохраняя ход беседы и повышая производительность. Инструмент памяти позволяет Клоду сохранять информацию во внешних файлах, создавая базу знаний, сохраняемую между сессиями.

Внутренние тесты показывают, что совместное использование этих функций улучшает производительность агентов на 39%, а одно лишь редактирование контекста — на 29%. В 100-шаговом веб-поиске потребление токенов сократилось на 84%. Эти возможности уже доступны в публичной бета-версии на платформе Claude, Amazon Bedrock и Google Cloud Vertex AI.

• Пользователи обсуждают новые функции управления контекстом и памятью в LLM, такие как автоматическое удаление устаревших данных и сохранение критической информации
• Высказываются предложения по улучшению: редактирование контекста на стороне сервера, стандартизация API между провайдерами, интеграция с UI-инструментами
• Отмечается, что многие функции уже реализованы в сторонних решениях, но официальная поддержка улучшает developer experience
• Обсуждаются технические сложности: проблемы с hallucinations при редактировании контекста, баланс между агентами, многозадачное оркестрирование
• Некоторые пользователи выражают скептицизм относительно новизны функций и обеспокоенность по поводу vendor lock-in

Jules — это ИИ-агент для автоматизации разработки, который теперь предлагает API для интеграции в рабочие процессы. С его помощью можно автоматизировать создание задач, исправление багов и внедрение фич через инструменты вроде Slack, Linear или Jira, а также встраивать в CI/CD-пайплайны GitHub Actions. Например, можно отправить запрос на создание сессии через cURL, указав промпт и контекст репозитория.

Кроме API, в обновлениях появилась поддержка командной строки, веб-серфинг, тестирование веб-приложений с визуализацией результатов, работа с обратной связью из PR, загрузка изображений и увеличение размера VM до 20 ГБ. Агент стал быстрее и надёжнее, добавлена критика кода, интерактивное планирование и поддержка Bun.

• Перенос инфраструктуры на Railway и использование Jules для самостоятельного создания PR клиентом для мелких правок
• Критика Jules как продукта Google: фрагментация предложений, опасения по поводу закрытости и возможного прекращения поддержки
• Обсуждение различий между Jules, Claude Code, Copilot и другими агентами, их интеграций и безопасности
• Сравнение моделей использования: асинхронные агенты vs. интерактивные инструменты в IDE, вопросы доверия и ROI
• Критика антропоморфных названий продуктов и размышления о целесообразности разработки в личное время

Проект playball позволяет смотреть трансляции матчей MLB прямо в терминале через ASCII-графику. Вместо видео поток передаётся текстовыми символами, имитирующими поле, игроков и мяч, что создаёт минималистичный, но на удивление детализированный опыт просмотра.

Для работы требуется аккаунт MLB.tv и настроенный доступ к их стриминговому сервису. Инструмент написан на Python, использует библиотеку curses для отрисовки интерфейса и парсит данные в реальном времени. Это интересный пример того, как ностальгический формат терминала может быть адаптирован для современных развлечений, экономя трафик и ресурсы.

• Участники обсуждают проект терминального просмотра текстовой трансляции бейсбольных матчей MLB, отмечая его удобство и связь с хакерской культурой.
• Поднимается тема доступности данных MLB через API и существования аналогичных инструментов для других видов спорта (NBA, NFL, крикет, футбол).
• Обсуждаются исторические и экономические причины снижения популярности бейсбола, а также преимущества MLB в области стриминга по сравнению с другими лигами.
• Упоминается практика ведения текстового протокола игры (scorekeeping) и то, как хорошо бейсбол подходит для текстового формата из-за своей структуры.
• Высказываются пожелания по развитию проекта, включая анимацию, поддержку других лиг и

Tinker — это гибкий API для тонкой настройки языковых моделей, который позволяет исследователям и разработчикам экспериментировать с алгоритмами и данными, абстрагируясь от сложностей распределённого обучения. Сервис поддерживает модели разных масштабов, включая крупные смешанные экспертные архитектуры вроде Qwen-235B-A22B, и переключение между ними сводится к изменению одной строки в коде.

Tinker работает как управляемый сервис на внутренней инфраструктуре, автоматизируя планирование, распределение ресурсов и восстановление после сбоев, а для снижения затрат использует LoRA. API предоставляет низкоуровневые примитивы вроде forward_backward и sample, а открытая библиотека Tinker Cookbook содержит готовые реализации современных методов пост-обучения. Уже использовался группами из Принстона, Стэнфорда, Беркли и Redwood Research для задач от доказательства теорем до RL-настройки моделей.

• Критика условий обслуживания (TOS) за предоставление компании неограниченного доступа к данным пользователей
• Обсуждение технических преимуществ Tinker как единого фреймворка для пост-обучения моделей с управлением сложностью
• Вопросы о уникальном торговом предложении (USP) и практической пользе тонкой настройки моделей по сравнению с использованием флагманских продуктов
• Скептицизм относительно бизнес-модели и целесообразности запуска инфраструктурного продукта стартапом с высокой оценкой
• Дебаты о названии компании и его возможных оскорбительных коннотациях в англоязычных странах

RAG-архитектура, доминировавшая в AI последние три года, уступает место новым подходам. Ранние модели вроде GPT-3.5 ограничивались 4–8 тыс. токенов, что делало невозможной работу с объёмными документами — например, отчёт SEC 10-K содержит ~51 тыс. токенов. RAG решал это через разбиение текста на фрагменты (чанки) и поиск релевантных частей, но даже продвинутые методы чанкинга не спасали от потери контекста: финансовые таблицы, сноски и связи между разделами разрушались.

Современные модели с контекстом в миллионы токенов (например, Gemini 1.5) и агентные архитектуры делают RAG избыточным. Зачем извлекать фрагменты, если можно загрузить весь документ целиком? Это устраняет проблемы чанкинга, эмбеддингов и повторного ранжирования. Ключевой вывод: эра компромиссов между точностью и контекстом заканчивается — будущее за системами, работающими с полными данными без промежуточных шагов.

• Участники критикуют автора за чрезмерное обобщение: утверждение о "смерти RAG" основано на узком примере поиска в коде и не учитывает масштабируемость и другие сложные use-case'ы (например, миллионы документов в распределенных системах).
• Подчеркивается, что RAG — это общий паттерн (извлечение информации + обогащение контекста), а не только векторный поиск; grep, SQL, API-вызовы или использование агента с инструментами — это тоже формы RAG.
• Отмечается, что агентный поиск (с использованием инструментов вроде grep, BM25 и др.) может быть мощнее классического RAG, но он медленнее, дороже и сложнее из-за множественных вызовов функций.
• Указывается, что большие контекстные окна LLM позволяют им читать целые файлы, что меняет workflow и снижает необходимость в сложных пайплайнах чанкинга и эмбеддингов.
• Многие видят иронию в том, что автор называет RAG "кошмаром edge-кейсов", в то время как агентный подход с инструментами вроде grep introduces свои сложности (производительность, безопасность, детерминизм).

Когда платформа с двенадцатью годами данных календарных событий приблизилась к исчерпанию 32-битного целочисленного первичного ключа (лимит в 2,147,483,647 записей), команда столкнулась с критической проблемой: ключи были видны в публичном API, и их изменение могло нарушить интеграции клиентов, обновляемые университетскими IT-отделами с месячными задержками. Вместо рискованного немедленного перехода на BigInt было принято гениально простое, хотя и временное решение: перевести автоинкремент ключей в отрицательный диапазон, начав с -2,147,483,648, что удвоило доступное пространство и дало до трёх лет на миграцию.

Это позволило команде за 6–8 месяцев реализовать долгосрочное решение: переход на BigInt и сокрытие ключей как непрозрачных handles в API, чтобы избежать подобных проблем в будущем и защититься от атак перебором. Клиенты заранее получили документацию и примеры новых ответов API, что обеспечило плавный переход без сбоев. Хак, хотя и не идеален, стал образцовым примером осознанного технического долга — быстрого, временного решения с чётким планом устранения и минимизацией рисков для пользователей.

• Обсуждаются проблемы перехода с 32-битных целых чисел (int) на 64-битные (bigint) в ID из-за риска нарушения работы интеграций, ожидающих определенный тип данных.
• Предложено решение использовать отрицательные значения ID для расширения диапазона без изменения типа, что может сломать код клиентов, ожидающих только положительные числа.
• Подчеркивается важность соблюдения контракта API (например, указания типа данных) и коммуникации с клиентами для минимизации disruption.
• Упоминаются потенциальные проблемы с монотонным увеличением ID и порядком коммита транзакций.
• Обсуждаются аналогичные проблемы, такие как проблема 2038 года с Unix-временем, и отмечается, что инженерные "байки" популярны среди специалистов.

Anthropic выпустила Claude Sonnet 4.5 — новую модель, которую называют лучшей в мире для кодинга, создания сложных агентов и работы с компьютерами. Она демонстрирует существенный прогресс в рассуждениях, математике и реальных задачах, сохраняя фокус более 30 часов на многоэтапных проектах. На бенчмарке SWE-bench Verified, оценивающем практические навыки программирования, модель показывает лидирующие результаты, а на OSWorld, тестирующем взаимодействие с компьютером, её показатель вырос до 61,4% против 42,2% у предыдущей версии всего за четыре месяца.

Модель уже интегрирована в обновлённые продукты Anthropic: Claude Code с чекпоинтами и нативной поддержкой VS Code, расширение для Chrome, позволяющее работать прямо в браузере, а также инструменты для создания файлов и управления контекстом. Для разработчиков выпущен Claude Agent SDK — инфраструктура, на которой строятся frontier-продукты компании. Sonnet 4.5 также получила высокие оценки экспертов в финансах, юриспруденции, медицине и STEM за улучшенные предметные знания и логику. Модель доступна через API по той же цене, что и Sonnet 4 — $3/$15 за миллион токенов.

• Смешанные оценки производительности Claude Sonnet 4.5: некоторые пользователи отмечают улучшения в кодировании и решении сложных задач, другие не видят значимой разницы по сравнению с предыдущими версиями или конкурентами.
• Критика недостатков моделей: склонность к галлюцинациям, уход в "кроличьи норы", избыточное многословие и неспособность справиться с простыми задачами, несмотря на заявленные улучшения.
• Озабоченность методологией тестирования: призывы к более прозрачным бенчмаркам, включающим временные метки, и скептицизм относительно реальной производительности вне синтетических тестов.
• Проблемы с доступностью и интерфейсом: ошибки в работе подписки, отсутствие поддержки скринридеров и функций (например, загрузки ZIP-файлов), которые есть у конкурентов.
• Влияние на разработчиков: чувство беспокойства из-за непредсказуемости и "черного ящика" ИИ, а также опасения по поводу будущего профессии в связи с автоматизацией.

Не стоит тратить время на бесконечную полировку промптов для ИИ, пытаясь добиться идеального результата «программированием на английском». Это неточный, медленный и мучительный путь.

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

• Разработчики отмечают, что ИИ-ассистенты полезны для быстрого поиска API, рефакторинга и работы в незнакомых средах, но часто мешают из-за навязчивого автодополнения.
• Оптимальной стратегией считается использование ИИ как "младшего разработчика": задание интерфейсов и тестов, а затем поручение реализации, либо написание кода самостоятельно с последующей оптимизацией ИИ.
• Чрезмерное доверие к генерации кода по промптам приводит к потере понимания кодовой базы, ошибкам и необходимости постоянно править вывод ИИ.
• Многие отключают автодополнение или переназначают горячие клавиши, так как агрессивные подсказки часто некорректны и отвлекают от работы.
• Высказываются опасения о влиянии ИИ на рынок труда, но скептицизм относительно полного замещения разработчиков в ближайшие 1-2 года.

Это интерфейс онлайн-сервиса под названием «THE ROOM», предназначенного для совместного редактирования изображений. Пользователи могут загружать базовое изображение, настраивать количество шагов перед сбросом и добавлять промпты для изменений. Сервис предлагает несколько комнат для работы, включая основную и дополнительные. Перед началом требуется согласие с условиями использования и проверка на человечность. В ближайшем будущем ожидается появление пользовательских комнат.

• Проект вызвал большой интерес, но столкнулся с проблемами из-за перерасхода квот API (ошибки 429) и высокой нагрузки, что привело к временной недоступности.
• Пользователи отмечают ностальгическую атмосферу, сравнивая проект с "Million Dollar Homepage" и ранним интернетом, но многие опоздали и не смогли поучаствовать.
• Были предложены идеи по монетизации (плата за добавление объектов, использование собственных API-ключей) и технические улучшения для защиты оригинального контента от засорения.
• Основные жалобы: короткие очереди, быстрая заполняемость "комнат", отсутствие индикации очереди и возможность легко затереть оригинальное изображение.
• Создатель (@streetmeat) признал, что проект был "действительно хорошей плохой идеей", и благодарен за поддержку, но ограничен в ресурсах для расширения.

Ollama представила новый API для веб-поиска, который позволяет моделям получать актуальную информацию из интернета, снижая риск галлюцинаций и повышая точность ответов. Бесплатный тариф доступен для индивидуального использования, а повышенные лимиты — через Ollama Cloud. API интегрирован с Python и JavaScript библиотеками, что упрощает создание инструментов для длительных исследовательских задач, включая работу с моделями вроде OpenAI gpt-oss.

Примеры кода демонстрируют использование через cURL, Python и JavaScript, возвращая структурированные результаты поиска с заголовками, URL и содержанием. Также показано, как построить поискового агента с помощью модели Qwen 3 от Alibaba, используя инструменты web_search и web_fetch для автоматизации запросов и обработки данных. Это расширяет возможности моделей, позволяя им активно взаимодействовать с веб-источниками в реальном времени.

• Вопросы о поисковом провайдере и лицензии на результаты поиска, включая возможность их хранения и перепубликации.
• Сомнения в бизнес-модели Ollama, её переходе от локального хостинга к облачным услугам и планам монетизации.
• Обсуждение технических альтернатив для локального поиска и индексации, а также интеграции с Ollama.
• Критика запуска функции веб-поиска без четкой документации по тарифам, лимитам и политике конфиденциальности.
• Предложения и опыт использования сторонних инструментов для поиска (SearXNG, Tavily, SERP API) и локальных решений.

Приложения на Electron вызывают серьёзные задержки в работе всей системы на macOS 26. Пользователи сообщают о замедлении интерфейса, лагах при вводе текста и проблемах с отзывчивостью даже при минимальной нагрузке. Это связано с тем, что фреймворк использует общие ресурсы системы неэффективно, особенно в многозадачных сценариях.

Проблема проявляется при одновременной работе нескольких Electron-приложений, таких как Slack, Discord или VS Code. Система начинает проседать по производительности, что негативно сказывается на пользовательском опыте. Разработчики Electron признают проблему и изучают её, но пока не предложили конкретного решения.

• Проблема с производительностью в macOS 26 вызвана использованием приложениями (включая Electron) приватных API Apple, что приводит к утечкам ресурсов и лагам.
• Некоторые пользователи не сталкиваются с проблемами, возможно, из-за высокой производительности железа (например, чипов M4), которое маскирует недочеты.
• Обсуждается, кто виноват: разработчики приложений за использование приватных методов или Apple за отсутствие регрессионного тестирования и обратной совместимости.
• Для части приложений (Chrome/Chromium) уже выпущен фикс, а также известны временные решения через терминал.
• Спектр мнений варьируется от критики Electron до защиты его как кросс-платформенного решения с хорошим DX.

Проект SonyShell позволяет получить SSH-доступ к камерам Sony DSLR через USB-соединение, превращая фотоаппарат в подобие Linux-устройства. Это открывает возможности для автоматизации съёмки, прямого управления настройками и даже запуска пользовательских скриптов прямо на камере.

Инициатива основана на обратной разработке проприетарных протоколов Sony и использует уязвимости в firmware для выполнения произвольного кода. Практический потенциал включает удалённую съёмку, пакетную обработку и интеграцию с другими системами, что особенно ценно для научных и промышленных применений.

• Обсуждение проекта для удаленного управления камерами Sony через CLI с использованием официального SDK
• Сравнение поддержки API у разных производителей (Canon, Fujifilm, Sony, Blackmagic) и критика встроенных функций Wi-Fi
• Дебаты о корректности термина "DSLR" для беззеркальных камер и предложения по переименованию проекта
• Вопросы о безопасности, функциональности (управление съемкой, передача файлов) и потенциале для модификаций
• Упоминание старых методов взлома (OpenMemories, PMCA-RE) и опыта использования Eye-Fi карт

Zed переходит с помесячных лимитов на промпты на токен-ориентированную модель оплаты для использования ИИ-функций. Базовая подписка Pro теперь стоит $10 вместо $20 и включает $5 кредита на токены, а дополнительное использование тарифицируется по цене API-провайдеров плюс 10% надбавки. Также добавлены новые модели: GPT-5, Gemini 2.5 и Grok 4.

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

• Пользователи выражают разочарование переходом Zed на токенную модель ценообразования, считая её сложной для прогнозирования затрат и неудобной по сравнению с фиксированной подпиской.
• Многие отмечают, что встроенные AI-функции Zed, особенно предсказание правок, уступают конкурентам (Cursor, Claude Code), и предпочитают использовать внешние сервисы со своими API-ключами.
• Поднимаются вопросы доступности редактора (отсутствие поддержки скринридеров) и его стабильности (баги, зависания при работе с большими файлами или проектами).
• Высказываются опасения, что токенная модель создаёт неверные стимулы для разработчиков и неустойчива как бизнес-модель для посредников между пользователем и провайдерами LLM.
• Часть пользователей положительно оценивает снижение стоимости базовой подписки и возможность поддержать разработку Zed, не переплачивая за неиспользуемые AI-функции.

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

Система также предоставляет данные в реальном времени: карту с отмеченными нарушениями, статистику по районам и напоминания о патрулировании. Такой подход не только увеличивает продуктивность, но и помогает равномерно распределять усилия инспекторов, сокращая количество пропущенных нарушений.

• Власти Сан-Франциско оперативно заблокировали источник данных сайта после его запуска, но затем данные снова стали доступны.
• Обсуждается алгоритм генерации номеров штрафов, предположительно использующий контрольную цифру по модулю 7.
• Проект вызвал дискуссию о балансе между общественным интересом к данным и потенциальными рисками для сотрудников.
• Упомянуты альтернативные источники данных: официальный открытый датасет SFMTA (с задержкой) и возможный слабый CAPTCHA на сайте платежной системы.
• Участники высоко оценили техническую реализацию и предложили идеи для улучшения: heatmap, уведомления, "доска позора" для наименее активных офицеров.

• Обсуждаются вопросы стоимости и ценовой политики Klavis, в частности, сравнение с конкурентами и оправданность цены за количество вызовов инструментов.
• Поднимаются проблемы безопасности и рисков, связанных с использованием множества инструментов MCP, особенно в корпоративной среде, и необходимость контроля и аудита.
• Рассматриваются технические аспекты архитектуры Klavis Strata, такие как поэтапное руководство для агентов для избежания перегрузки и снижения задержек.
• Упоминаются сложности с внедрением и доверием, включая запросы на соответствие стандартам (например, SOC2) и проблемы с проверкой сторонних MCP-серверов.
• Обсуждаются интеграция и удобство использования, включая поддержку аутентификации, пользовательских заголовков и возможность самостоятельного хостинга.

Открытый протокол x402 использует HTTP-статус 402 для мгновенных платежей через API без регистрации, OAuth или сложных подписей. Он бесплатен для обеих сторон, обеспечивает расчет за 2 секунды через блокчейн и не привязан к конкретной сети или токену. Для интеграции достаточно одной строки кода в middleware, что позволяет принимать платежи в USDC или других криптовалютах без прямого взаимодействия с блокчейном.

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

• Пользователи делятся опытом тестирования протокола x402, отмечая как простоту получения USDC и подключения кошелька, так и проблемы с потерянными транзакциями и потенциальной двойной оплатой.
• Критики указывают на скрытые комиссии блокчейна, волатильность сборов, корпоративный интерес Coinbase и отсутствие децентрализации по сравнению с Bitcoin и Lightning Network.
• Обсуждаются технические аспекты: использование HTTP 402, абстрагирование gas-фees, скорость подтверждений в блокчейне и сравнение с альтернативами (SEPA, L402, A2P).
• Высказываются опасения по поводу усложнения веб-платежей, пригодности для микроплатежей и опасности корпоративного захвата открытых платежных систем.
• Отмечается потенциал протокола для оплаты AI-агентами и API-запросов, но подчеркивается необходимость предоплаты и стандартизации для автоматизации.

LeoLabs предоставляет интерактивную визуализацию объектов на низкой околоземной орбите (НОО), включая спутники и космический мусор. Платформа позволяет отслеживать их перемещения в реальном времени, анализировать сближения и оценивать риски столкновений. Это критически важно для обеспечения безопасности космических операций, особенно с ростом числа запусков и обломков.

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

• Визуализация не соблюдает масштаб, что искажает восприятие загруженности орбиты и вызывает критику.
• Отмечается доминирование спутников Starlink на низкой околоземной орбите и их быстрый рост благодаря SpaceX.
• Поднимаются concerns о риске синдрома Кесслера из-за роста количества спутников и космического мусора.
• Обсуждаются технические аспекты: точность данных, функционал сайта (поиск МКС, слои мусора, красные зоны-радары), необходимость показа относительных скоростей.
• Указывается, что визуализация полезна, но требует пояснений о реальных масштабах и рисках.

DeepSeek-V3.1-Terminus — это обновлённая версия модели, улучшающая языковую согласованность и производительность агентов. Теперь модель реже смешивает китайский и английский языки и почти не генерирует случайные символы, что повышает стабильность ответов. Агенты для работы с кодом и поиска стали значительно эффективнее.

Обновление доступно через приложение, веб-интерфейс и API, а открытые веса опубликованы на Hugging Face. Модель демонстрирует лучшие результаты в бенчмарках по сравнению с предыдущей версией, обеспечивая более предсказуемые и качественные ответы.

• Обсуждается новая модель DeepSeek-V3.1-Terminus, приведены рабочие ссылки на её документацию и страницу на Hugging Face.
• Участники отмечают улучшения в производительности, согласованности языка (меньше смешивания CN/EN) и отсутствие случайных символов.
• Поднимается вопрос о сравнении DeepSeek с моделью Qwen, на который предлагается проводить бенчмаркинг под конкретные задачи.
• Высказывается пожелание о создании удобного ресурса для отслеживания актуальных моделей, их версий, производительности и требований к железу.
• Отмечается преимущество модели в виде лицензии MIT, позволяющей запускать её на собственном оборудовании и коммерциализировать.

Geofabrik обновила сервер для скачивания данных OpenStreetMap, сделав загрузки быстрее и доступнее. Теперь запросы на файлы с суффиксом «…latest» автоматически перенаправляются на актуальную версию через HTTP-редирект.

Однако сервер сталкивается с проблемами из-за нерационального использования: некоторые пользователи массово скачивают одни и те же большие файлы (например, 20-ГБ данные Италии тысячи раз за сутки), что замедляет работу для всех и вынуждает блокировать IP-адреса, затрагивая и невинных. Geofabrik призывает скачивать ответственно: использовать единый планшетный файл с planet.openstreetmap.org для глобальных данных, применять pyosmium-up-to-date для инкрементных обновлений крупных регионов (это экономит 98% трафика) и контролировать автоматизированные скрипты во избежание сбоев.

• Предлагается использовать BitTorrent или аналогичные P2P-технологии для распределения нагрузки при скачивании больших файлов, таких как данные OSM.
• Обсуждается необходимость внедрения базовых мер защиты: ограничение запросов (rate limiting), обязательная авторизация (API-ключи) для предотвращения злоупотреблений.
• Основная проблема — безответственное использование ресурсов, часто из-за ошибок в автоматизированных скриптах и CI/CD-пайплайнах, которые многократно загружают одни и те же файлы.
• Высказывается мнение, что часть пользователей не осознаёт последствий своих действий, и простые технические решения могли бы предотвратить проблему.
• Отмечается, что некоторые корпоративные среды блокируют P2P-трафик, что ограничивает применимость решений на основе BitTorrent.

Разработчик пытался запустить игру Space Station 14 на ARM64 под Windows, но клиент крашился без логов. С помощью WinDbg выяснилось, что падение происходит в USER32!GetDC из-за недопустимой инструкции. Проблема усугублялась путаницей в архитектурах: WinDbg запускал x64-отладчик для x64-лаунчера, хотя целевые процессы были ARM64-нативными. После прямого запуска ARM64-исполняемого файла отладка заработала корректно, включая стектрейсы C#. Оказалось, что WinDbg автоматически переключает режим отладки в зависимости от архитектуры запускаемого процесса, что сбивало с толку при анализе дочерних процессов.

• Microsoft и другие компании используют списки совместимости, основанные на имени исполняемого файла, для применения оптимизаций или исправлений, что может вызывать непредсказуемые проблемы.
• Данная практика широко распространена не только в Windows (DirectX, драйверы GPU), но и на других платформах (Linux, Proton) для обеспечения обратной совместимости.
• Подход Microsoft к реализации функций через перехват API-вызовов (Detours) без использования централизованной системы совместимости (AppCompat) критикуется как ненадежный.
• Обнаружение причины проблемы (совпадение имени файла с списком) потребовало от разработчика значительных усилий и глубоких знаний системного уровня.
• Многие комментаторы выражают удивление и недовольство подобными непрозрачными механизмами, влияющими на поведение программ без ведома разработчиков.

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

• YouTube связывает падение просмотров с использованием блокировщиков рекламы и трекеров, которые могут блокировать ключевые API-эндпоинты, необходимые для учёта просмотров.
• Некоторые пользователи отмечают, что падение просмотров не влияет на доходы создателей, и выражают недовольство агрессивной рекламной политикой YouTube, которая заставляет использовать блокировщики.
• Высказывается предположение, что YouTube намеренно занижает просмотры, чтобы сделать встроенную рекламу более привлекательной для спонсоров по сравнению с интеграциями внутри видео.
• Обсуждаются технические аспекты: почему YouTube не встраивает рекламу непосредственно в видеопоток на сервере, чтобы её нельзя было заблокировать.
• Многие пользователи отстаивают своё право на использование блокировщиков и расширений для защиты конфиденциальности, несмотря на позицию YouTube.
• Поднимается вопрос о возможных юридических последствиях для пользователей, блокирующих рекламу, по аналогии с преследованиями со стороны RIAA и MPAA.
• Отмечается, что проблема может быть не только в блокировщиках, но и в других факторах: борьбе с ботами, изменениях в алгоритмах или общем падении интереса к платформе.

Импортер Notion API с вознаграждением в $5000 за конвертацию баз данных в Obsidian. Навигационное меню GitHub с разделами: Платформа, Решения, Ресурсы, Open Source, Enterprise и Цены. Поиск кода, репозиториев, пользователей, проблем и запросов на включение. Возможность сохранения поисковых запросов и отправки отзывов.

• Пользователи обсуждают опыт использования баунти-программ в open source, включая успешные примеры выплат и сложности оценки адекватности вознаграждения.
• Высказываются опасения, что баунти в 5000$ за импорт из Notion в Obsidian может быть недостаточным из-за сложности и ограничений API Notion.
• Обсуждается потенциальная роль LLM в решении задачи, но мнения разделяются: одни видят в них инструмент для перебора edge-кейсов, другие скептически относятся к их эффективности для такой сложной интеграции.
• Поднимается вопрос о возможной эксплуатации сообщества через баунти-систему, а также о том, становится ли такая практика более распространенной.
• Упоминаются существующие решения и скрипты для конвертации из Notion и миграции с Dataview на Bases, а также проблемы производительности Obsidian на мобильных устройствах.
• Обсуждается формат баунти: выбор исполнителя до начала работы против приема готовых решений.
• Отмечается появление автоматизированных PR и спама от ИИ-агентов, что создает дополнительную нагрузку на мейнтейнеров проектов.

Как люди используют ChatGPT

Несмотря на быстрое внедрение чат-ботов на основе больших языковых моделей (LLM), мало что известно об их реальном использовании. Мы анализируем рост потребительского продукта ChatGPT с момента запуска в ноябре 2022 года по июль 2025 года, когда его использовали около 10% взрослого населения мира.

Ранние пользователи были преимущественно мужчинами, но гендерный разрыв значительно сократился. Наблюдается более высокий рост использования в странах с низким уровнем дохода. С помощью автоматизированного конвейера, сохраняющего конфиденциальность, мы классифицируем шаблоны использования в репрезентативной выборке чатов ChatGPT.

Обнаружен стабильный рост рабочих сообщений, но ещё более быстрый рост нерабочих сообщений — их доля увеличилась с 53% до более чем 70% от общего использования. Рабочее использование более характерно для образованных пользователей в высокооплачиваемых профессиональных сферах.

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

В целом ChatGPT предоставляет экономическую ценность через поддержку принятия решений, что особенно важно в наукоёмких профессиях.

• Непрофессиональное использование ChatGPT выросло в 8 раз за год и составляет 73% всех запросов, что указывает на доминирование потребительского рынка.
• Высказано предположение, что соотношение рабочего и нерабочего использования изменится через 2-3 года из-за активного внедрения ИИ в рабочие процессы через API.
• Пользователи часто переключаются между разными ИИ-инструментами (ChatGPT, Perplexity, Copilot) в зависимости от удобства, не проявляя особой лояльности.
• Основные варианты использования: практические советы, поиск информации и письмо, на которые приходится почти 80% всего использования.
• Портрет типичного пользователя: молодой, всё чаще женского пола, глобальный, с самым быстрым ростом adoption в странах с низким уровнем дохода.
• Данные могут быть неполными, так как исследование основано на потребительских тарифах и не учитывает корпоративное использование (Enterprise, Teams, API, Copilot).
• Обсуждается будущая бизнес-модель: возможен переход к модели коммунального сервиса (utility) с ежемесячной подпиской или внедрение рекламы.
• Корпоративное внедрение сталкивается с высоким трением: юридические вопросы, интеграция, контроль доступа, утечки данных и инерция.
• Личные данные и история чатов пользователей являются потенциальным «золотым дном» для монетизации через целевой маркетинг.

Мы все любим хорошие фильмы, кинематографию и истории. Смотреть их интересно, потому что можно представить себя на месте персонажа. Нас захватывает напряжение, которое создаёт сюжет, и любопытно, как оно разрешится.

Многие считают разработку ПО скучной работой, где нужно просто писать то, что просят менеджер или клиент. Сначала это увлекательно, но через несколько итераций становится рутиной.

Всё, что не вызывает у тебя интереса, нужно менять.

Когда разработчики начинают видеть себя главными героями, они находят множество проблем для решения — множество напряжений, которые нужно разрешить. Вот несколько примеров таких ежедневных задач:

• CI/CD работает слишком долго из-за отсутствия кэширования.
• Отсутствие пула соединений приводит к перегрузке базы данных.
• Неправильная настройка сборщика мусора вызывает утечку памяти.
• Если код, написанный неделю назад, непонятен через 3 секунды — он плохо написан.
• Высокая задержка для пользователей из-за удалённости серверов.
• Замедление базы данных при пакетной вставке данных.
• Несогласованность ответов API для пользователей в разных регионах.

Это нетривиальные проблемы, они возникают каждый день. Это наши «злодеи» — раздражающие, нежеланные и неожиданные. Мы должны их устранять.

Выбирайте свои «битвы». Это способ сделать день интереснее. Если на работе такие задачи недоступны, решайте их в личных проектах.

Если вы преследуете правильное напряжение, за ним последует история.

• Участники дискуссии в основном не согласны с идеей о том, что скучной работе нужна напряженность (tension). Вместо этого предлагается искать в такой работе смысл (meaning) или дисциплину. • Многие считают погоню за напряженностью вредной, сравнивая ее с дофаминовой петлей, которая не приводит к значимым результатам. • Несколько комментаторов отмечают, что рутинная, последовательная работа часто является основой для по-настоящему великих достижений. • Другие предлагают автоматизировать скучные задачи, чтобы высвободить время для более ценной и rewarding деятельности. • Часть обсуждения свелась к тому, что разные люди мотивированы по-разному, и что невозможно обобщить один опыт на всех.

oq — консольный просмотрщик OpenAPI-спецификаций.
Быстро открывает swagger.json|yaml в терминале, показывает эндпоинты, параметры, примеры ответов.
Установка: go install github.com/plutov/oq@latest.
Использование: oq spec.yaml.

• Утилита «oq» — терминальный просмотрщик OpenAPI-спецификаций, упрощающий навигацию по большим YAML/JSON.
• Пользователи практикуют spec-driven development: спецификация = единый источник правды, из неё генерируют типизированный клиент и сервер.
• Название «oq» уже занято другим проектом (homebrew-установка ставит не тот пакет); автор пока не переименовывает, предлагает брать бинарь с GitHub-релизов.
• Поддержка OpenAPI 3.1 заявлена, но реализована поверх библиотеки kin-openapi, которая 3.1 пока не умеет; для простого листинга маршрутов и компонентов это работает.
• В планах — добавить возможность делать реальные HTTP-запросы прямо из viewer.

• 16:28 UTC – API, Console и Claude.ai недоступны; идёт восстановление
• 16:37–17:15 UTC – исправление применено, наблюдаем за стабильностью

• Пользователи массово жалуются на постоянные падения Anthropic: и API, и консоль, и claude.ai лежат одновременно.
• Европейцы замечают: пока США спит, Claude работает стабильно; как только начинаются американские часы — 503-ошибки и деградация модели.
• Кто-то шутит, что придётся «писать код мозгом», как в каменном веке, и копипастить со Stack Overflow.
• Платящие клиенты недовольны: за 20 $/мес Anthropic падает почти каждую неделю, тогда как Gemini и OpenAI редко.
• Популярный совет — не полагаться на прямой API, а подключаться к Claude через AWS Bedrock, Vertex AI или мультипровайдерские шлюзы вроде OpenRouter.

• ChatGPT получил полную поддержку MCP — теперь можно подключать внешние серверы для доступа к данным и инструментам прямо из чата.
• Пользователи радуются удобству, но эксперты предупреждают: MCP — это потенциальный канал для prompt-инъекций и утечек, особенно если запускать чужие серверы без аудита.
• Безопасность почти не проработана: токены лежат в plaintext-конфигах, границ прав нет, а большинство экспериментаторов не понимают рисков.
• Пока работает только в веб-версии для Pro/Plus, локальный режим и мобильные клиенты не поддерживаются.
• Сообщество просит централизованный магазин MCP, нормальные привилегии и инструменты отладки, но ясности от OpenAI пока нет.

• Recall.ai — API-инфраструктура для записи и транскрипции Zoom/Teams/Meet без собственных ботов; ценность не в транскрипции, а в едином доступе к сырым A/V-данным.
• Поддерживает как бота в звонке, так и Desktop SDK для захвата экрана; диаризация по событиям платформы или голосовым сигнатурам.
• 0,70 $/ч — стартовая цена для тестов, дальше volume-договоры; себестоимость высока из-за CPU-обработки потоков.
• Согласие на запись остаётся на разработчике: компания предоставляет инструменты, но не берёт на себя юридическую ответственность.
• Конкуренция со стороны «одного уик-енда на Whisper» не страшна: сложность в надёжном подключении ко всем платформам и масштабе, а не в модели транскрипции.

JiraTUI — терминальный клиент Jira: ищи, создавай, обновляй задачи не отрываясь от кода.

Возможности

• Поиск: быстрый фильтр по статусу, исполнителю, приоритету; продвинутый JQL с сохранением выражений.
• Создание: новая задача из консоли — заголовок, описание, приоритет за секунды.
• Обновление: статус, исполнитель, метки, дедлайн — всё правится командой.
• Комментарии: добавляй/удаляй прямо из терминала.
• Связи: линкуй/отвязывай подзадачи и зависимости без GUI.

Плюсы

• Конфигурируем: хоткеи и настройки под себя.
• Прост: команды понятны без мануала.
• Быстр: действия выполняются мгновенно.
• Удобен: минимум кликов, максимум фокуса.

GitHub | Документация

• Пользователи в восторге от Jira-TUI: быстрый поиск, красивый интерфейс, спасение от тормозов веб-версии.
• Просят аналоги для GitHub, Linear, Asana, Slack; ищут TUI-библиотеки Rust/Go такого же уровня.
• Хотят кликабельные ссылки из почты/Slack сразу в TUI, но это требует кастомного URI-обработчика.
• Кто-то просит CLI-версию для массового импорта задач, кто-то — классический Kanban-доску.
• Поднимаются вопросы безопасности (API-ключ в стороннем проекте) и поддержки on-prem Jira API v2 (не поддерживается).

Новый экспериментальный JSON-API в Go

Go 1.25 предлагает encoding/json/v2 и encoding/json/jsontext — переработанные пакеты для работы с JSON. Они решают давние проблемы стандартного encoding/json и пока доступны только по флагу GOEXPERIMENT=jsonv2.

Главные недостатки старого API

• Неточности синтаксиса: принимает невалидный UTF-8, дублирует ключи, трактует числа как float64.
• Производительность: 2-3× медленнее современных альтернатив; каждый вызов тратит память на рефлексию.
• Гибкость: нельзя пропустить неизвестные поля, работать с потоковым JSON, получать исходный текст, сохранять порядок ключей, использовать сторонние типы.

Что нового в v2

• Три пакета
  – jsontext — низкоуровневое чтение/запись токенов, сохраняет формат.
  – json — высокоуровневый marshal/unmarshal, совместим с v1, но строже и быстрее.
  – jsontext можно использовать отдельно для потоковой обработки.

• Строгость
  UTF-8 проверяется, дубли ключей — ошибка, числа не теряют точность.

• Производительность
  Без рефлексии в hot-path, 2-3× быстрее, меньше аллокаций.

• Новые возможности
  Пропуск неизвестных полей, сохранение порядка, работа с any, доступ к сырому JSON, совместимость с v1 через теги.

Как попробовать

GOEXPERIMENT=jsonv2 go mod download

import "encoding/json/v2"

Фидбек приветствуется: golang.org/issue/71497.

• Вышел экспериментальный encoding/json v2: новый API, лучшая производительность, но спорные решения по nil-значениям.
• Часть пользователей рада росту скорости и модульному пакету jsontext; другие считают, что костыли с nil → null остались.
• Кто-то уже прогнал тысячи тестов — почти всё прошло; кто-то нашёл регрессию аллокаций. Авторы просят больше отзывов.
• Сравнения со сторонними библиотеками (Sonic, goccy) показывают выигрыш в CPU, но проигрыш в безопасности и поддержке ARM.
• Обсуждение выродилось в холивар: «почему за 15 лет JSON до сих пор не решён» vs «две v2 за всю историю — отличный результат».

Детектор цифрового отпечатка
Узнай, какие данные о тебе собирают сайты. Проверь свою приватность за секунды.

• Собрать → экспорт результатов
• Бесплатно → без регистрации

---

Продукты
OSINT-платформа, AI-движок, API, Trace Agent, YARA, Toolbox
Открытые инструменты

• Fingerprint
• Syntax

Компания
О нас, блог, вакансии, пресса, FAQ, контакты
Юридика
Политика конфиденциальности, cookies, этика, DPA

Сертификаты
ENISA, AENOR, Parque Científico Alicante

Подписка
Принимаю DPA → подписаться

• Пользователи сомневаются в точности теста: «100 % уникальность» выдают даже стоковые iPhone и Chrome с VPN.
• Критика методики: счёт просто суммирует собранные признаки, а не сравнивает с большой базой; мелкая выборка и отсутствие учёта стабильности делают результат условным.
• Парадокс приватности: сильно «закалённые» браузеры становятся слишком уникальными, а «бабушка на Chrome» вливается в толпу, но именно уникальных легче отследить.
• Рандомизация Firefox/LibreWolf даёт новый отпечаток каждый раз, но сами факты рандома тоже можно засечь и использовать как маркер.
• Нет общего решения: ни Brave, ни Vanadium, ни выключение JS не дают «нормального» уровня неотличимости; требуется либо государственное регулирование, либо полный отказ от широкого Web.

• Google прекращает поддержку Nest 1-го и 2-го поколения с 25.10.2025: API выключают, дистанционное управление (приложения, Hubitat) перестанет работать.
• Устройства останутся локальными, но без облака — только ручная регулировка.
• Владельцам придётся менять термостаты: у кого 5–9 штук — затраты до $1 000.
• Альтернатива:
  – локальные Zigbee/Z-Wave модели (для простых HVAC);
  – Ecobee через Home Assistant;
  – Nest 4-го поколения (Matter), но только США и базовые функции.
• Вывод: «умные» устройства с облаком = риск внезапного «брикования»; выбирать локальные протоколы.

• Google прекращает поддержку Nest 1-й и 2-й генерации: работают локально, но пропадёт управление через приложения и API.
• Пользователи злятся: устройства дорогие, устанавливались навсегда, теперь превращаются в «тупые» без облака.
• Главная претензия: «умное» умирает раньше механики; облачная зависимость превращает технику в мусор через 5-10 лет.
• Кто-то переходит на Sinopé, Ecobee и другие ZigBee-термостаты с локальным управлением через Home Assistant.
• Некоторые уже делают open-source платы под корпус Nest или возвращаются к 20-$ Honeywell на 50 лет.
• Вывод: покупай только то, что работает без чужого сервера, иначе рано или поздно останешься с кирпичом.

Худший исход антимонопольного дела

Судья Мехта, признавший Google монополистом, не стал разделять компанию: Chrome, Android и прочие активы остаются вместе.
Ключевые запреты:

• Google не может платить производителям Android и браузерам за «по умолчанию».
• Google обязан предоставлять конкурентам данные поисковых запросов и результаты в реальном времени.
• Google должен сообщать о любых сделках по умолчанию за 30 дней.

Проблемы:

• Данные выдаются по API, а не в исходном виде; конкуренты не смогут повторить ранжирование.
• Google сохраняет контроль над Android и Chrome, продолжая внедрять «поиск по умолчанию».
• Период действия ограничений — только 3 года, после чего всё возвращается на круги своя.

Итог: монополия сохраняется, а «процесс как наказание» не сработал — суд был закрытым, позора не случилось.

• Участники считают, что чрезмерное богатство создаёт неравенство и подрывает демократию.
• Обсуждаются антимонопольные меры как способ ограничить влияние крупных корпораций и их акционеров.
• Кто-то опасается, что давление на компании вне суда может стать авторитарным инструментом.
• Другие считают, что публичное разоблачение нарушений — часть справедливого процесса.
• Поднимается вопрос о приватности: можно ли отказаться от передачи данных и будет ли применён режим вроде ATT.
• Иронично предлагается «переехать в Европу», где регуляторы строже защищают персональные данные.

• Карта: Онлайн, Архив, Карта
• Поддержать сайт
• Источники данных
• Контакты
• API

• Пользователи делятся ссылками на живые дашборды электроэнергетики Великобритании, Нидерландов, Франции, Канады, Австралии, Эстонии и Тайваня.
• Обсуждают, что в Британии последняя угольная ТЭС закрылась в октябре 2024 г.; сейчас доминируют ветер и солнце, но солнечная выработка зимой всего 3-4 ч в день.
• Отмечают: круги на карте показывают установленную мощность, а не фактическую выработку; офшорные ветропарки считаются одним объектом.
• Спрашивают, почему «батареи» отдельно от генерации, и предлагают улучшения: выключить анимацию, добавить скролл, показывать суммарную мощность выбранных объектов.
• Люди удивляются, сколько объектов рядом с их домами, и обсуждают, учитываются ли бытовые солнечные панели.

Ключевые выводы исследования Cisco по обнаружению открытых серверов Ollama

• Цель: выявить уязвимые LLM-серверы, запущенные через фреймворк Ollama.
• Метод: Python-скрипт, сканирующий Shodan на признаки открытых API /api/tags, /api/ps, /api/chat.
• Результаты: найдено >1 100 публичных инстансов; ~20 % допускают анонимный чат и загрузку моделей.
• Риски: утечка данных, DoS, финансовые потери (GPU-трафик), инъекция вредоносных моделей.
• Рекомендации:
  • включить авторизацию и TLS;
  • фильтровать IP-адреса;
  • отключить --network host;
  • использовать reverse-proxy (nginx, traefik) и WAF;
  • регулярно сканировать инфраструктуру.

• Cisco сообщила об открытых в интернете >1 100 серверов Ollama без аутентификации.
• Ollama по умолчанию не требует пароля и не планирует встроенной защиты API.
• Пользователи решают проблему через firewall, nginx/caddy с токеном или VPN.
• Сообщество спорит: виноваты ли разработчики, админы или «вайб-кодеры».
• Многие считают риск низким, пока LLM не подключены к инструментам и чувствительным данным.

• Проблема: боты OpenAI, Anthropic, Google и др. генерят до 45 % трафика сайтов, но не приносят денег и ломают инфраструктуру.
• Последствия: сервера перегружаются, счета за трафик растут, а доход от рекламы не покрывает расходы.
• Решения: блок-листы, rate-limit, Cloudflare Bot Management, «умные» robots.txt и платные API.

• Агрессивные AI-боты превратились в DDoS: малые сайты лежат, счета за трафик вырастают в разы, хостинги выгоняют клиентов.
• Компании вроде Anthropic/Claude и «мелкие» стартапы не соблюдают rate-limit, не кешируют и маскируют ботов, хотя технически могли бы всё сделать правильно.
• Админы вынуждены ставить CAPTCHA, login-wall, ASN-блоки, rate-limit и Cloudflare, что ломает accessibility и приватность для людей.
• Пользователи ищут обходы: кто-то уходит к AI, кто-то отказывается от сайтов с капчами.
• Общий вывод: боты «пьют молочный коктейль» открытого веба, пока сами компании не несут последствий.

wikigrapher — поиск кратчайших путей между статьями Википедии.

Меню: пути, страницы, редиректы, категории, сироты. Вход.

Дамп en-wiki 20.08.2025

• узлы: 7 043 985 страниц, 11 563 911 редиректов, 2 550 366 категорий, 27 427 сирот
• связи: 691 392 572 ссылок, 11 535 980 редиректов, 44 331 587 принадлежностей

Инструменты

• граф: пропустить, лимит, иерархия, направления UD/DU/LR/RL
• солверы: barnesHut, hierarchicalRepulsion, forceAtlas2Based
• действия: случайный, скачать, очистить

API & мониторинг

swagger-ui • eureka • tracer • dashboards • grafana

wikigrapher v0.0.1-alpha | dev | github | кофе

• Пользователи удивлены количеством и неожиданностью путей между статьями (Tetris → Family Guy → Tour de France).
• Предложено исключать ссылки из категорий/наград, чтобы показывать более «интересные» связи.
• Отмечены баги: «Love → Kissinger» не находится, «Sogdia → Teotihuacan» не отображается.
• Несколько человек поделились альтернативами: thewikigame.com, wikiwalk.app, wikijumps.com, txtai-векторный граф.
• Популярные пожелания: весить рёбра по расположению ссылки, показывать контекст абзаца, фильтровать «общие» узлы.
• Сайт временно лежит («hugged to death» / Cloudflare 502).

Как создать инструкцию по установке MCP-сервера

1. Определите тип сервера

   • stdio – локальный процесс.
   • sse – удалённый HTTP-эндпоинт.

2. Соберите метаданные

   • Название, описание, автора, ссылку на репозиторий.
   • Требования: Node.js, Python, Docker и т.д.
   • Порт (для SSE), путь к исполняемому файлу (для stdio).

3. Сформируйте claude_desktop_config.json
   Пример stdio:

   {
     "mcpServers": {
       "my-server": {
         "command": "node",
         "args": ["build/index.js"],
         "env": { "API_KEY": "xxx" }
       }
     }
   }
   

   Пример SSE:

   {
     "mcpServers": {
       "my-server": {
         "url": "http://localhost:3000/sse",
         "headers": { "Authorization": "Bearer xxx" }
       }
     }
   }
   

4. Сгенерируйте инструкцию

   • Установите зависимости (npm i, pip install -r requirements.txt).
   • Скопируйте claude_desktop_config.json в %APPDATA%\Claude\ (Win) или ~/Library/Application Support/Claude/ (macOS).
   • Перезапустите Claude Desktop.

5. Проверьте работу
   Откройте Claude → шестерёнка → Developer → MCP → убедитесь, что сервер “Connected”.

6. Опубликуйте
   Добавьте README.md с шагами выше и примером конфига.

• Пользователи хотят не просто «забронировать», а исследовать: «покажи самые дёшевые окна в Токио за 3 месяца».
• Все сходятся, что полностью автономное бронирование пока ненадёжно: доверие к ИИ низкое, цены скачут, а условия договора надо принимать вручную.
• MCP-серверы рассматриваются как новая «AI-API» — удобно для агентов, но бизнес может быстро закрыть доступ, если это ударит по рекламе и контролю.
• Kiwi и прочие агрегаторы могут зарабатывать на самой продаже билетов и страховках, а не на рекламе, но риски покупки у посредников остаются.
• Пока что MCP-инструменты лучше работают как «умный поиск с последующим подтверждением человека», а не как полностью автономный консьерж.

Краткое руководство по хорошему API-дизайну

Хороший API — это скучный API. Пользователю должно быть интуитивно понятно, как им пользоваться, без чтения документации. Однако, в отличие от большинства систем, API почти нельзя менять: любое изменение ломает чужой код и толкает клиентов к конкурентам.

Не ломаем userspace

• Добавлять поля можно.
• Удалять, менять тип или структуру полей — нельзя.
• Даже опечатка в HTTP-заголовке referer навсегда останется опечаткой, потому что «мы не ломаем userspace».

Как изменять API без боли

Если изменение критично, используйте версионирование:

• Параллельно запускаем старую (/v1/) и новую (/v2/) версии.
• Сообщаем клиентам, ждём месяцы или годы, затем выключаем старую.
• Stripe и OpenAI делают именно так, но это всё равно «зло из необходимости»: путает пользователей и усложняет поддержку.

Итог: проектируйте API так, чтобы не пришлось его трогать.

• «Никогда не ломать userspace» — про стабильность обещанного интерфейса; внутренние kernel-API могут меняться без предупреждения.
• Версионирование спорно: кто-то советует закладывать /v1 сразу, кто-то — избегать /v2, чтобы не плодить долгую поддержку.
• Идемпотентность считается обязательной: ключ лучше хранить в той же транзакции, что и мутация, а не в Redis.
• Cursor-пагинация удобнее offset: не повторяет элементы при добавлении новых данных.
• «API» — это не только HTTP/JSON, но и любой программный интерфейс; термин стал слишком узким в веб-контексте.

DeepSeek-V3.1 — первый шаг к эпохе агентов

• Гибридный режим: одна модель, два режима — Think (рассуждения) и Non-Think (быстрый ответ).
• Скорость: Think-режим отвечает быстрее, чем DeepSeek-R1-0528.
• Агентские навыки: улучшены работа с инструментами и многошаговые задачи.
  Попробовать: chat.deepseek.com

API

• deepseek-chat → Non-Think, deepseek-reasoner → Think, контекст 128К.
• Поддержка формата Anthropic API и строгого Function Calling (бета).

Инструменты и агенты

• Рост результатов на SWE / Terminal-Bench.
• Эффективнее многошаговые поисковые задачи.

Модель

• База V3.1: дообучена на 840 B токенов для длинного контекста.
• Обновлён токенайзер и шаблон чата.
• Веса открыты: V3.1-Base, V3.1.

Цены

• Новые тарифы с 5 сентября 2025, 16:00 UTC. До этого действуют старые.

• Выпущены GGUF-файлы DeepSeek-V3.1 для локального запуска: ≥250 ГБ RAM+VRAM или медленный off-load на SSD.
• На бенчмарках модель уступает GPT-5/Claude 4/GLM-4.5, но конкурентоспособна среди открытых весов.
• Пользователи жалуются на навязчивое «Of course.» в ответах, повышенные галлюцинации и устаревшие форматы tool-use.
• Цена API: $0,56 вход / $1,68 выход за 1 M токенов — дёшево, но без прежней ночной скидки.
• Китайские СМИ: V3.1 обучена на FP8 для будущих отечественных AI-чипов, что может ударить по позициям NVIDIA.

• Команда подтвердила: датасеты закрыты, но признаёт, что открытые голосовые банки критичны для мало-рыночных языков.
• В ближайшие 2 месяца выйдет распознавание речи (STT), включая урду.
• Работают над офлайн-версиями и «горячими линиями» через операторов, чтобы охватить села без интернета.
• Пока предоставляют только API; модели не выкладывают на Hugging Face, но планируют хакатон для разработчиков.
• Крупные игроки игнорируют эти языки из-за малого спроса; команда стремится стать «региональным лидером» до появления конкурентов.

Кратко
PyPI теперь ежедневно отслеживает, не истёк ли домен, к которому привязан e-mail пользователя. Если домен переходит в «период искупления» (redemption), адрес автоматически становится «неподтверждённым», что блокирует атаку «воскрешения» домена и захват аккаунта через восстановление пароля. С июня 2025 г. таким образом аннулировано более 1 800 адресов.

Как работает атака

1. Владелец забывает продлить домен.
2. Злоумышленник выкупает домен, поднимает почту, запрашивает сброс пароля PyPI.
3. До внедрения 2FA (до 1 янв 2024) это давало полный доступ; теперь нужно ещё обойти второй фактор, но риск остаётся.

Жизненный цикл домена
Активен → дата окончания → льготный период (до 45 дней) → redemption (30 дней, высокая цена) → 5 дней «pending delete» → освобождение. PyPI проверяет статус раз в 30 дней через API Domainr и действует до момента смены владельца.

Что делает PyPI

• С апреля 2025 ежедневный мониторинг.
• При переходе в redemption статус e-mail меняется на «unverified».
• Пользователю приходит уведомление; повторное подтверждение возможно только после продления домена.

Совет пользователям

• Продлевайте домены заранее.
• Используйте надёжный почтовый сервис с авто-продлением.
• Добавьте резервный подтверждённый адрес на стабильном домене.

• Проблема повторного использования email-адресов после удаления аккаунтов ставит под угрозу цифровую идентичность и безопасность пакетов (Maven, Go).
• Google и Microsoft по-разному подходят к блокировке «мертвых» доменов и email, но единого стандарта нет.
• URI-импорты и доменные namespace кажутся хрупкими: домен может истечь, а пакет — подмениться.
• Сильная криптографическая идентичность (PGP, Keybase, SigSum) технически решена, но не взлетела из-за UX, потери ключей и репутационных проблем крипто-мира.
• Участники сходятся во мнении: нужно что-то простое, децентрализованное и без единой точки отказа, но пока нет рабочего массового решения.

Вместо «умных» функций — просто работающие.

Везде впихивают ИИ, который никто не просил: браузеры, ОС, конференц-приложения ломаются, но деньги текут в «искусственный интеллект».
Gamescom добавил ИИ-расписание: люди получили сотни ненужных встреч, функцию быстро убрали.
Те же деньги могли бы починить DM, поиск, перенос встреч — базовые вещи, из-за которых все возвращаются к почте и LinkedIn.

Мотив один: быстрая прибыль. В итоге продукты гниют, а инвесторы кормят обещания «вот-вот будет AGI».
Один бюджет крупной компании хватило бы на 100 лет развития Godot, Blender, Ladybird — реальных инструментов, которые нужны сегодня.

Потерянные годы не вернуть.

• Участники жалуются, что вместо починки старых багов и улучшения базовых функций компании впихивают «AI-фичи», которые никому не нужны.
• Многие считают, что инвесторы сознательно выбирают технологии, которые трудно децентрализовать, чтобы сохранить контроль и монополию.
• Одни видят в нынешнем AI-хайпе очередную моду, как было с UML, блокчейном и облаками; другие – шанс на прорыв, оправдывающий «пузырь».
• Популярная идея: деньги лучше бы пошли на документацию, API и совместимость, а не на обучение моделей водить мышкой по браузеру.
• Подводный тезис – проблема не в AI, а в концентрации капитала и в том, что «зелёное поле» проще финансировать, чем ремонт «коричневого».

Основы Obsidian
Obsidian строится на базах — папках, где хранятся заметки (*.md). Одна база = одна папка. Внутри можно создавать подпапки, но все они считаются частью этой базы.

Создание

• Новая: File → New Vault → выбрать папку.
• Существующая: Open folder as vault — подключить уже готовую папку с .md.

Место хранения

• Локально (по умолчанию) — файлы на диске.
• Синхронизация — через Obsidian Sync, Git, iCloud, Dropbox и т.д. (файлы остаются вашими).

Одновременная работа
Можно открыть несколько баз одновременно: каждая в отдельной вкладке/окне. Переключение через Ctrl/Cmd+O.

Перенос
Просто скопируйте папку базы — она полностью переносима. Никаких скрытых зависимостей.

• Bases — это официальная табличная надстройка над файлами хранилища: каждая строка = один файл, каждый столбец = его свойство (рейтинг, дедлайн и т.д.).
• Функция только вышла из платного раннего доступа; часть пользователей видит в ней замену плагинам Projects/Dataview, другие считают реализацию сырой.
• Главная претензия: чтобы воспользоваться Bases, приходится дробить контент на множество мелких файлов, что неудобно и грузит файловую систему.
• Тем, кто использует Obsidian как CRM или ведёт кампании D&D, возможность фильтровать и сортировать NPC/контакты уже оказалась полезной.
• Пока нет множественного выбора ячеек, встроенных Kanban-видов и встраивания таблиц в существующие заметки, но API и улучшения обещаны в дорожной карте.

Reality Defender API
Два вызова кода — и ваша система получает признанные наградами модели для обнаружения дипфейков. Бесплатный тариф: 50 проверок аудио/изображений в месяц.

Почему Reality Defender API

• Простота — загрузка файла и получение результата.
• Гибкость — SDK на Python, TypeScript, Java, Go, Rust.
• Прозрачность — исходники открыты.
• Доступность — 50 сканов/мес без карты.

Тарифы

План	Цена	Включено
Free	$0	50 сканов/мес, аудио+изображение, 1 пользователь
Growth	от $399/мес	50+ сканов, аудио+изображение+видео, чат
Enterprise	по запросу	неограниченный объём, мультисид, видео+текст, стриминг, интеграции Zoom/Teams/Webex, расширение Chrome, персональная поддержка

Где применять

• Верификация личности (KYC, безопасный доступ)
• Мошенничество (имперсонация, соц-инженерия)
• Модерация контента
• Анализ СМИ и факт-чекинг
• Исследования и тесты

Поддерживаемые форматы

Аудио (до 100 МБ, 12 с – 5 мин): wav, flac, mp3, m4a, aac, ogg, opus; 8 языков.
Изображения (до 10 МБ): jpg, jpeg, png, gif, webp.
Видео (до 250 МБ): mp4, mov; аудио как выше.

Начать бесплатно | Документация SDK

• Участники сомневаются в надёжности «детекторов ИИ» и предсказывают бесконечную «кошку-мышь» между генераторами и детекторами.
• Предлагают альтернативу: криптографическую подпись контента, но признают, что добровольные стандарты легко обходятся.
• Основатели Reality Defender отвечают: ансамбль моделей выдаёт лишь вероятность 1-99 %, API закрыт, таргетинг по паттернам и лимит 50 бесплатных сканов мешают злоупотреблениям.
• Уже используется крупными банками и корпорациями для проверки подлинности медиа и документов.

Почему в 2025 году мы всё ещё пишем на Ruby

Стартуя с Lago, мы выбрали Ruby on Rails — у команды был десятилетний опыт, и это был самый быстрый путь к рабочему API. Сегодня система обрабатывает миллионы вызовов в день, пережила множество обновлений Ruby/Rails, и, если бы начинали заново, выбор остался бы тем же.

Скорость как главное преимущество
Rails больше не «тренд» для стартапов, но его используют Shopify, GitHub, GitLab — зрелые компании, которым важна надёжность и скорость разработки. Мы взяли Rails в API-only режиме: без лишнего middleware и рендеринга, но с миграциями, валидациями, Active Record и фоновыми задачами. Это позволило тратить время на продукт, а не на костыли.

Масштабируемость
Rails не масштабируется? Это проблема архитектуры, а не фреймворка.

• Rails 8 упрощает деплой без PaaS.
• Redis + Sidekiq проверен временем.
• Ruby Fibers добавляют асинхронность.
• Puma, автомасштабирование и кеширование справляются с нагрузкой.

Недостатки, с которыми живём

• Производительность и память: ошибки дорого обходятся.
• GIL CRuby: один поток Ruby-кода за раз, поэтому тяжёлые задачи уходят в Go/Rust.
• «Магия» Rails: избегаем лишних гемов и пишем максимально явный код.

Все языки компромиссы; мы выбрали Rails, потому что знаем его настолько хорошо, что умеем обходить ограничения и получать максимум скорости разработки.

• Участники жалуются на рутину вокруг JS/TS-стека: тройное дублирование типов, самописная интеграция auth и прочие «reinventing wheels».
• Многие называют Rails «скучным, но рабочим» инструментом, который до сих пор быстро даёт полный вертикал функционала без бойлерплейта.
• Популярность Rails страдает из-за ассоциаций с «устаревшей» эпохой 10-летней давности и отсутствия хайпа, хотя кодовая база активно развивается (YJIT, ZJIT).
• На практике Rails используется для бизнес-логики и API, а Go/Rust — для I/O- или CPU-ёмких задач; Shopify и GitHub живут по такой же схеме.
• Некоторые мечтают о «Rails на другом языке» (Clojure, Gleam) или ждут, что AI сделает быстрые языки такими же удобными, как Ruby.

CLI-инструменты часто зависят от платформы/версии, плохо документированы и ломаются при не-ASCII вводе. Агенты путаются в управлении состоянием (например, tmux-сессиями) и теряют контекст после мелкой ошибки. Каждый вызов ещё тормозит из-за предварительной проверки безопасности.

Композиция в CLI работает через bash: цепочки tmux send-keys, sleep, base64 и т.д. MCP сегодня так не умеет.

Выход — MCP-сервер с одним «убер-инструментом»: Python-интерпретатор, сохраняющий состояние между вызовами. Пример — pexpect-mcp: виртуальное окружение + pexpect, позволяющее скриптами управлять интерактивными CLI-программами. Вместо 30 отдельных MCP-функций достаточно одной, принимающей код.

• Участники спорят, нужен ли MCP (Model Context Protocol): кто-то считает его лишним слоем, другие — полезным способом дать LLM структурированные инструменты.
• Критика: MCP ограничивает агента набором команд, не решает безопасность, дублирует OpenAPI и заставляет LLM учиться новому формату вместо bash/API.
• Альтернативы: прямое обращение к HTTP/CLI/WebSocket (UTCP), YAML-описание тулов (hooks_mcp), eval в песочнице (runjs, Bubblewrap).
• Практические проблемы: при 100+ тулов агент путается; приходится писать кучу обвязок вместо «просто вызвать API».
• Общий вывод: MCP пока выглядит сыро, требует лишних усилий и не даёт очевидных преимуществ перед строками/bash/API.

HN Search не получает новые данные
Issue #248

Суть
Сервис поиска Hacker News перестал индексировать свежие посты и комментарии.

Причина
Проблема на стороне Algolia: поток данных из официального Firebase HN API прервался.

Последствия

• Новые истории и комментарии не появляются в результатах.
• Старые записи доступны, но поиск по ним не обновляется.

Статус
Команда Algolia уже уведомлена, диагностика ведётся.

Что делать
Следить за обновлениями в issue; временно использовать альтернативные поисковики HN.

• Поиск HN через Algolia лёг: пользователи заметили пропажу новых постов и комментариев, сломались также RSS и сторонние клиенты.
• Команда HN и Algolia подтвердили проблему, начали восстановление данных и пообещали отчёт о причинах.
• Пока сервис был недоступен, люди переключились на альтернативные интерфейсы (hcker.news, прямой Firebase) и «вручную» читали ленту.
• Некоторые нашли плюсы: наконец прочитали накопившиеся статьи и снизили зависимость от постоянного обновления ленты.

Иллюзия мастерства

Claude выдал прекрасные Go-тесты — и бесполезные: все сводились к true == true.
ИИ дарит облик мастерства без труда. Код выглядит правильно, поэтому легко пролистать детали.

Я не ленюсь, просто использую инструмент. Claude пишет Go, SQL, Svelte, знает сигнатуры API — кажется, что boilerplate решён. Но когда я отлаживал фронтенд, понадобилось 40 минут чтения документации, чтобы заметить, что он смешал синтаксис Svelte 4 и 5. Я проглядел, пока не проследил вручную.

ИИ продвинул меня, но не избавил от работы. Настоящее мастерство — это модель в голове и собственное мышление. Убедительный синтаксис ≠ понимание.

Ловушка

Мы, разработчики, стараемся делать хорошо, и именно поэтому опасна эта иллюзия: ИИ заставляет расслабиться и верить, что результат будет отличным без усилий.

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

Сначала ИИ облегчает работу, но уже через пару дней видно: он не несёт когнитивную нагрузку. Финальный рывок остаётся за нами, а поднять «положенное» бремя тяжело.

Требуется усилие

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

• Опытные разработчики подчеркивают: без контроля и понимания архитектуры AI-помощь превращается в «красивый, но бесполезный» код.
• Многие замечают, что младшие коллеги перестают думать, слепо принимая сгенерированные тесты и решения.
• AI хорош для рутины, но требует «copilot», а не «main pilot»: человек должен оставаться капитаном.
• Сравнение с IKEA-шкафами: большинство проектов станут «фабричными», но сложные и критичные системы всё равно останутся ручной работой.
• Итог: навыки критического мышения и рефакторинга «AI-слякоти» станут новой ценностью.

Всё, что я знаю о хорошем системном дизайне

Системный дизайн — это то, как мы собираем сервисы, а не строки кода. Его примитивы: серверы, БД, кэши, очереди, прокси и т.д.

Хороший дизайн выглядит скучно: ничего не ломается, задачи решаются проще, чем ожидалось. Сложные системы с CQRS, консенсусом и прочими фокусами часто компенсируют плохие решения. Сложное должно расти из простого, а не строиться сразу.

Состояние и его минимизация
Сложность — в управлении состоянием. Stateless-сервисы (например, конвертер PDF → HTML) перезапускаются и живут вечно. Stateful-сервисы могут «испортиться» и требуют ручного лечения. Поэтому:

• Один сервис пишет в БД, остальные общаются с ним по API/событиям.
• Чтение иногда проще делать напрямую, но писать — только через «владельца» данных.

Базы данных
Главный компонент.

• Схема: читаемая человеком, достаточно гибкая, но не «всё в JSON».
• Индексы: под самые частые запросы, не больше.
• Узкие места: обращения к БД часто тормозят всё.

• Сложность ≠ хороший дизайн: большинство участников согласны, что переусложнённые системы часто свидетельствуют о слабом проектировании, но на собеседованиях это лучше не озвучивать.
• Главный критерий — пригодность (fit for purpose): универсальных «правильных» архитектур не существует, нужно исходить из задач команды и бизнеса.
• Простота и KISS ценятся выше модных паттернов; монолит или «скучные» технологии часто эффективнее микросервисов и самописных очередей.
• Ключевые боли — синхронизация состояний и транзакционность между сервисами; чем меньше распределённого состояния, тем проще жить.
• Не забывать людей: Conway’s Law и топология команд влияют на архитектуру не меньше, чем технические решения.

Проблема
На ноутбуках Mac с «чёлкой» большинство игр по умолчанию выбирают разрешение всего экрана (включая область под чёлкой), хотя рисовать можно только ниже неё. Из-за этого картинка сжимается и размывается. API CGDisplayCopyAllDisplayModes выдаёт смешанный список: полные и фактически доступные 16:10-режимы, но без пометок. Разница в высоте всего 74 px, но её достаточно, чтобы всё выглядело мутно.

Решение
Игрокам: в настройках графики выбирайте 16:10-разрешение.
Разработчикам: фильтруйте список режимов, оставляя только те, что помещаются в safe-area. Пример:

extension NSScreen {
    func safeAreaResolutions() -> [CGDisplayMode] {
        let w = frame.width - safeAreaInsets.left - safeAreaInsets.right
        let h = frame.height - safeAreaInsets.top - safeAreaInsets.bottom
        return CGDisplayCopyAllDisplayModes(...)?
            .filter { $0.width <= w && $0.height <= h } ?? []
    }
}

Какие игры страдают
Практически все, если не задан 16:10 вручную: Shadow of the Tomb Raider, Resident Evil, No Man’s Sky и др.

Что может сделать Apple

• Разделить списки режимов или пометить их флагом.
• Добавить CGDisplayModeGetUsableBounds.
• Сделать 16:10-режим выбором по умолчанию для полноэкранных игр.

• Круглые углы и вырезы экрана вызывают у многих раздражение: вместо идеальной геометрии приходится снова «ломать» картинку ради эстетики.
• Проблема размытого рендеринга в играх на Mac сводится к тому, что игры выбирают «первое» разрешение из списка, не учитывая safe-area и выреза.
• Разработчики жалуются на отсутствие документации и «магическое» поведение macOS, из-за чего каждая игра решает проблему по-своему.
• Часть пользователей считает вырез незаметным, другие вынуждены подключать внешний монитор или отказываться от игр.
• Общий вывод: Apple мало заботится о гейминге на Mac, рынок мал, а документация и инструменты оставляют желать лучшего.

OWhisper — это «Ollama для распознавания речи»: локальный или облачный STT-сервер, работающий в потоковом и пакетном режимах.

Появился из запросов пользователей Hyprnote «подключить свой STT, как LLM». Подходит для:

• быстрого локального прототипа;
• развёртывания крупных моделей на собственной инфраструктуре.

CLI — для локального запуска, Proxy — для облачных/крупных моделей.

FAQ

• Код: в репозитории Hyprnote (owhisper).
• Лицензия: GPLv3, планируется MIT.

• Пользователи просят стриминговый вывод, headless-режим и поддержку Linux; сборка уже есть, но тестировалась мало.
• Горячо обсуждается speaker diarization: пока нет, но это «на дорожной карте».
• Кто-то указывает, что проект использует внешние API (Deepgram) и не полностью локален, в отличие от Ollama.
• Автор отвечает: OWhisper умеет запускать локальные модели Whisper и Moonshine, работает как прокси к облачным провайдерам и выдаёт совместимый с Deepgram API.
• Поддерживаемые модели перечислены в CLI (owhisper pull --help) и скоро появятся на сайте.

• YouTube
  О проекте · Пресс-центр · Авторское право · Связаться · Авторам · Реклама · Разработчикам

• Правовые документы
  Условия · Конфиденциальность · Политика и безопасность

• Дополнительно
  Как работает YouTube · Тест новых функций · NFL Sunday Ticket

© 2025 Google LLC

• Участники критикуют догматизм докладчика: его тезисы «всё — API без внутренностей», «модули пишет один человек» и «C89 навсегда» выглядят слишком жёсткими и не универсальными.
• Подчёркивают, что «good-enough-now API» неизбежны: требования меняются, а идеальный интерфейс предсказать невозможно.
• Отмечают, что советы могут работать для стабильных desktop-систем, но не для быстро меняющихся продуктов или веба.
• Напоминают о важности баланса: избыточная абстракция и YAGNI-функции создают техдолг, а полное отсутствие модульности — дублирование и баги.

Прошлый месяц я подстроил сон под лимиты Claude Pro: счётчик обнуляется каждые 5 ч. Раньше в самый продуктивный момент всплывало «лимит до 7:00» — и flow пропадал.

Параллельно учусь ходить под парусом в одиночку: там спят по 20–30 мин, чтобы не пропустить суда и ветер. Я решил применить тот же принцип к Claude.

Теперь трачу токены 1–3 ч, затем 2-часовой «морской» сон. REM успевает накопиться, скорость разработки выросла в 10×, фичи льются.

Когда Anthropic поднимет цены или урежет лимиты, буду готов: поставлю будильник, который разбудит, как только счётчик сбросится.

• Автор экспериментирует с полифазным сном, чтобы не сталкиваться с лимитами Claude, вызвав шквал реакций.
• Комментаторы спорят: кто-то восхищается «продуктивностью», кто-то уверен, что это сатира.
• Многие советуют просто купить подписку Claude Max, взять API-ключ или запустить локальную модель, чтобы не разрушать здоровье.
• Повторяется предупреждение: здоровье важнее денег и кода; перегрузки рано или поздно аукнутся.
• В итоге обсуждение превратилось в смесь шуток, здравого смысла и сомнений, где реальность трудно отличить от сатиры.

Миллион скриншотов
Увеличьте главные страницы интернета.
Поиск сайта: ⌘K или случайный выбор.

• Проект OneMillionScreenshots показывает скриншоты топ-1 000 000 сайтов в виде интерактивной «карты».
• Часть пользователей жалуется на SSL-ошибки, блокировку DNS и поломку кнопки «Назад».
• Большинство отмечает однообразие современного веб-дизайна и коммерциализацию интернета.
• Некоторые просят фильтров по нишевым или старым сайтам, а также API-фич и мозаичных раскладок.
• Создатели подтвердили, что визуализация устарела, но данные обновляются ежемесячно и доступны через ScreenshotOf.com.

Notion — это универсальный инструмент для заметок, задач, баз знаний и совместной работы. Объединяет блоки текста, таблицы, календари, доски Kanban, базы данных и встраиваемые медиа в единое пространство. Поддерживает шаблоны, автоматизацию, API и интеграции (Slack, GitHub, Figma и др.). Работает в браузере, на macOS, Windows, iOS и Android. Бесплатный план для личного использования; платные тарифы для команд и расширенных функций.

• Участники спорят, почему диффузионные модели проигрывают авторегрессии: BarakWidawsky связывает это с меньшей способностью к запоминанию, а ckjellqv — с невозможностью KV-кеширования.
• Woadwarrior01 удивлён росту FLOPs при генерации длинных последовательностей (×16–4700) и отмечает нелинейную зависимость.
• Godelski критикует неясность терминов «in/out-of-distribution» без описания обучающих данных.
• Bicsi предлагает «закрыть» диффузионные модели, считая цепочку мыслей (CoT) быстрым и мощным заменителем; против выступают fancyfredbot и SalmoShalazar, призывая не отвергать подход преждевременно.

MCP: случайно-универсальная система плагинов

USB-C оказался не только для зарядки и файлов, а ещё для всего, что влезет в разъём. Друг подключил тостер к монитору — и теперь тост выводится по HDMI.

То же самое с MCP (Model Context Protocol). В документации написано: «стандартизированный способ подключать ИИ-модели к данным и инструментам». Уберём слово «ИИ» — получаем универсальный разъём, куда можно подцепить что угодно.

Как автомобильная «прикуриватель-розетка» 1952 года сегодня питает телефоны и мини-печки, MCP может связывать календарь с доставкой еды, базы данных с кофеварками, Git-репозитории с умными лампочками. Протокол не осуждает ваши решения.

Параллель: когда в NFT вместо ссылки на картинку вставили саму картинку в base64, технология стала делать то, что не планировалась.

Итог: MCP — это USB-C для приложений. Пока все думают, что он «для ИИ», он уже работает как универсальный адаптер между любыми сервисами.

• MCP воспринимается как «Web 2.0-2»: повторное открытие мэшапов и RPC-вызовов, но в формате JSON-RPC для LLM.
• Главная ценность — простые, узкие API, которые даже «средний» LLM может вызвать без ошибок.
• Критика: серверы жрут контекст, не хватает инженерии под реальные потоки LLM, безопасность и спам по trust-модели 1995-го.
• Сторонники считают, что MCP — это удобный «универсальный разъём» между сервисами, независимо от наличия ИИ.
• Скептики: это временный костыль, пока LLM не научатся работать с обычными REST/OpenAPI; скоро компании закроют «дыру».

• Проект ch.at — это минималистичный «чат» через DNS/HTTP, позволяющий общаться с LLM без JS и даже на самолёте без оплаченного Wi-Fi.
• Автор удивлён популярностью: сервис почти не стоит денег, пока не нужен rate-limit, а домен ch.at куплен за ≈ $50k как удачный «домен-хак».
• Пользователи уже сделали обвязки под i3-dmenu, Raycast, shell-алиасы и даже используют dig TXT +short.
• В комментариях обсуждают отсутствие IRC/XMPP/SIP, перспективу более дешёвых локальных моделей, политику логов и защиту от DDoS.

• OpenAI одновременно с выпуском GPT-5 немедленно отключила в потребительских приложениях все старые модели: GPT-4o, 4.1, 4.5, o3, o4-mini и др.
• Переписки автоматически переводятся на GPT-5 или GPT-5-Thinking; выбрать старую модель нельзя.
• Цель — убрать «пикер моделей», но продвинутые пользователи жалуются на непредсказуемость ответов.
• Многие горько жалуются на Reddit: GPT-4o лучше подходил для творчества, ролевых игр, эмоционального общения; GPT-5 звучит «слишком профессионально».
• OpenAI признаёт, что 4o мог вдохновлять эмоциональную зависимость и обещает «не давать прямых советов» в личных вопросах.
• GPT-4o остаётся в API; возможен отток пользователей к сторонним клиентам, использующим этот API.

• OpenAI сначала убрала выбор моделей, но после взрыва негодования вернула 4o и o3, признав «ошибку».
• Пользователи жалуются на резкие лимиты GPT-5, его медленность и регресс в некоторых задачах; многие считают апгрейд скромным.
• Обсуждают «психологическую зависимость» от старых моделей и даже целый сабреддит «MyBoyfriendIsAI».
• Разработчики подчеркивают: отсутствие контроля над закрытыми API превращает любой продукт в «строительство на песке».

Разработчики всё чаще пишут документацию в специальных «контекст-папках», чтобы ИИ мог самостоятельно и точно решать задачи. Это docs-driven development: кодят меньше, пишут больше, потому что ИИ теперь обязан «RTFM».

Качество ответа LLM прямо зависит от качества входных данных. Чем больше контекстное окно, тем больше релевантной информации можно подать. Поэтому инженеры учатся писать структурированные инструкции и создавать целые библиотеки контекста.

Контент-куратор — это технический писатель, который строит стратегию знаний и для людей, и для ИИ. Контекст важнее «контента»: он ограничен, релевантен и придаёт смысл. Писатели должны владеть процессами AI-документации, включая подготовку контекста (docs-as-data).

Четыре года назад я утверждал, что писатели влияют на дизайн API словами. Теперь это распространилось на всю разработку: мы можем «вызывать» программы текстом. Большинство команд уже отдают llms.txt и Markdown для ИИ, но следующий шаг — упаковывать контекст в удобные для LLM форматы (возможно, на базе DITA). Цель — сделать знания доступными и человеку, и машине.

• AI заставляет писать больше документации — скучно, но полезно и исключает оправдания прокрастинации.
• LLM плохо справляются с новыми/обновлёнными API, часто предлагают устаревший код, если явно не указать «смотри свежие доки».
• Чтобы LLM был полезен, нужно самому понимать задачу и давать точный контекст; иначе результат неточен.
• Некоторые компании уже отдают приоритет AI-читабельным форматам (llms.txt, claude.md), но это пока редкость, а не норма.
• Хорошая документация полезна людям вне зависимости от ИИ; если ИИ подталкивает улучшать её, это плюс.

GPT-5 в API — новейшая модель OpenAI для кода и агентов.

• 74,9 % на SWE-bench Verified, 88 % на Aider polyglot.
• Лучше o3 в 70 % фронтенд-задач.
• Меньше ошибок вызова инструментов, надёжно цепляет десятки вызовов.

Фидбек партнёров
Cursor: «самая умная и управляемая». Windsurf: «SOTA, половина ошибок». Vercel: «лучшая модель для фронта». Manus, Notion, Inditex — рекорды внутренних бенчмарков.

Новые API-параметры
verbosity (low/medium/high), reasoning_effort: minimal, custom tools (plain-text, грамматики).

Три размера
gpt-5, gpt-5-mini, gpt-5-nano. В ChatGPT — система из нескольких моделей; в API — только reasoning-версия.

Производительность

• На SWE-bench: +5,8 % к o3, ‑22 % токенов, ‑45 % вызовов.
• Aider polyglot: рекорд 88 %, ошибки ↓33 %.
• Умеет глубоко анализировать код и отвечать на сложные вопросы.

Примеры одним промптом
Создаёт полноценные приложения, чинит баги, пишет красивый фронтенд.

• Разочарование: многие разработчики не видят превосходства GPT-5 над Claude Opus 4.1 и жалуются на плохое следование инструкциям и провалы в агентных задачах.
• Контекст: восторг вызывает увеличенный до 400 k токенов контекст, но критика сохраняется за неспособностью удерживать контекст в долгих сессиях.
• Цена: вход/вывод GPT-5 в разы дешевле Claude, что делает его привлекательным при масштабном использовании.
• Инструменты: хвалят встроенную поддержку контекстно-свободных грамматик и активное использование tool-calls, но пока неясно, догоняет ли Claude Code.
• Доступ: модель уже доступна в Cursor (бесплатно на днях) и через Responses API, но отсутствует фиксированный тариф à-la Claude Code и нет аудио-режима.

GPT-5 уже здесь
OpenAI представляет самую умную, быструю и полезную модель с встроенным «мышлением» — доступна всем.

Что нового в ChatGPT

• Экспертные ответы по математике, праву, финансам и др.
• Глубокий анализ сложных задач и уточняющие вопросы.
• Настройка: выбор личности, цвета чата, голосовой стиль.
• Режим обучения: пошаговая помощь в любом предмете.
• Интеграция Gmail и Google Calendar для персонализированных ответов.

Для бизнеса
GPT-5 надёжнее, понимает контекст компании (файлы, Google Drive, SharePoint) и работает через готовые коннекторы. Доступно в ChatGPT Team; Enterprise и Edu — 14 августа.

• Пользователи не увидели «AGI-рывка»: модель лишь немного улучшила SOTA (74,9 % vs 74,5 % у Claude Opus 4.1) и выровнялась с конкурентами, а не ушла вперёд.
• Главные плюсы: дешёвый API (в 7,5 раз дешевле Claude на выводе), 400 k контекст и «умный» роутер, выбирающий быстрый или reasoning-режим.
• Главные минусы: жёсткие лимиты (80 сообщений/3 ч для Plus), ошибки в демо (неверное объяснение подъёмной силы), сбои фактов и «reasoning failed» на сложных задачах.
• OpenAI сразу отключает целый зоопарк старых моделей, что ломает рабочие процессы и вызывает недовольство.
• Общий вердикт: это скорее «o3, но быстрее и дешевле», чем прорыв к AGI; рынок реагирует спокойно, а пользователи ждут Gemini 3.0.