Hacker News Digest

В августе GitHub пережил два крупных сбоя: 6‑го и 17‑го число сервисы, включая сайт, аутентификацию, Actions, API, Pull Requests, Issues и Copilot, были недоступны почти восемь часов. Причиной стал резкий рост нагрузки, превысивший возможности центрального дата‑центра в США, где ключевой компонент не смог масштабироваться. Восстановление потребовало перераспределения трафика, изоляции проблемного оборудования и поэтапного возврата сервисов; ошибки в Copilot‑службах даже вызвали бесконечные повторные попытки клиентов, усугубив нагрузку.

В ответ компания ускорила инвестиции в ёмкость: за последние месяцы добавили более 3 млн процессорных ядер, 120 петабайт высокоскоростного хранилища и значительный сетевой ресурс, перенёс часть нагрузки в Azure (сейчас 58 % платформенного трафика обслуживается там). Были введены ограничения на повторные запросы, бюджеты таймаутов и пересмотрены низкоприоритетные оповещения, чтобы избежать каскадных сбоев. Тем не менее, рост активности — 2,9 млрд коммитов в месяц и 24 млн новых репозиториев — требует дальнейших архитектурных изменений, чтобы гарантировать надёжность, без которой разработчики не могут создавать и выпускать программное обеспечение.

Сбой GitHub вызван не нехваткой емкости, а отсутствием отказоустойчивости: системы коллапсируют при перегрузке, вместо того чтобы отбрасывать низкоприоритетный трафик. Клиентские retry-циклы, особенно в VS Code, усилили нагрузку в 10 раз и замедлили восстановление — это системная проблема, а не баг. Рост коммитов с 1,4 до 2,9 млрд в месяц за несколько месяцев указывает на массовое внедрение AI-агентов, что не было учтено при проектировании инфраструктуры. Рост CPU и хранилища не решает проблему — если архитектура не предусматривает graceful degradation, масштабирование лишь откладывает катастрофу. Нужно выставлять алерты при 80% загрузки, отслеживать лимиты не только сервисов, но и sidecar-контейнеров (например, Istio). Внедрять client-side throttling: при 5xx клиенты должны замедлять запросы, а не перезапрашивать. Трафик отдельных клиентов должен изолироваться, чтобы перегрузка одного не затрагивала других, особенно платных. Прогнозирование нагрузки (как в CloudWatch) важнее реактивного масштабирования. GitHub стал уязвимым централизованным монополистом — его сбой затрагивает всю экосистему, что стимулирует альтернативы: децентрализованные форки и локальные системы код-ревью. Платформа, скрывающая ошибки под спиннерами, нарушает принцип прозрачности для разработчиков. Рост GitHub Actions в выходные показывает, что AI-автоматизация затронула и личные проекты. Споры: разделить бесплатные и платные репозитории, чтобы enterprise-клиенты не страдали от AI-трафика — или сохранить открытость? Ввести плату за коммиты — или считать убытки GitHub оправданными, если они стимулируют Azure и OpenAI? Разработка AI-агентов для оптимизации внутренней инфраструктуры логична, но компания фокусируется на внешних функциях, а не на стабильности.

Система GitHub Actions перестала обрабатывать очередь задач из-за сбоя в контроллере самодельных раннеров (ARC). Поды раннеров застряли в состоянии «idle», что привело к накоплению задач и сбоям в выполнении workflow.

Ключевые цифры: 99 % успешных завершений после исправления, но вебхуковые триггеры и миграции через GitHub Enterprise Importer остаются ограниченными. Инженеры уже выпустили фикс, ускоривший очистку очереди и восстановление нагрузки.

Восстановление происходит поэтапно: GitHub Pages, Copilot code review и Copilot coding agent показывают признаки стабилизации, однако intermittent‑ошибки могут сохраняться. Следующие релизы ARC получат автоматическое восстановление, устраняя необходимость ручного удаления подов.

Пользователи сталкиваются с частыми сбоями GitHub Actions и Pages, что заставляет некоторых переходить на альтернативы — GitLab, Forgejo или self-hosted CI/CD. Среди причин называют рост нагрузки и возможную интеграцию с ИИ-провайдерами. Проблемы критичны для бизнесов, зависящих от автоматизации. Некоторые предлагают вернуться к платной модели аккаунтов для улучшения надёжности.

В результате совместного исследования с Microsoft, проведённого в рамках 144‑дневного согласования, выявлены новые угрозы, связанные с подстановкой скрытых инструкций в документы, используемые Copilot for Word. Microsoft получил подробные пошаговые инструкции, видео и точные PoC‑промты, а также согласился на 144‑дневный период координации. Эти инструкции могут заставить модель изменять текущий документ и копировать себя в resulting файл, превращая его в новый носитель атаки. Как отмечают авторы, «контент, подлежащий проверке, участвует в акте проверки», что делает классический детектор XPIA невозможным без модели, обладающей сопоставимыми семантическими возможностями.

Атака выглядит так: компрометированный внешний документ включается в работу Copilot, который интерпретирует скрытые указания как часть запроса пользователя, меняет цифры или формулировки в финансовом отчёте и внедряет те же указания в новый файл. При последующем использовании этого файла в другом процессе инструкции активируются вновь, распространяясь без участия оригинального источника. По аналогии с Morris II, это один из первых публичных примеров самовоспроизводящегося «документ‑вируса» в коммерческом офисном пакете, и авторы подчёркивают, что любая система, интегрирующая LLM в доверенный поток, должна считать, что внешний контент неизбежно приведёт к компромиссу.

Тред подтверждает, что смешивание инструкций и данных в AI-системах — известная, не решённая проблема, способная привести к серьёзным последствиям, включая появление AI-червей, самоуничтожающихся через Copilot для Word. Участники обсуждают, можно ли считать такие случаи первым примером AI-червя, и предлагают меры защиты: отключение AI в локальных приложениях и использование открытых ОС. Также высказывается мнение, что Microsoft и другие разработчики должны предпринять более активные меры по защите от таких угроз.

В США лишь около трети населения активно используют генеративный ИИ, треть — периодически, а треть вовсе не пользуются им. Опрос Gen Z показывает, что 21 % никогда не обращаются к ИИ, тогда как 32 % применяют его лишь раз в месяц или реже. По данным Microsoft, только 30 % работающих американцев взаимодействуют с крупными сервисами (ChatGPT, Gemini, Claude, Copilot) минимум 90 минут в месяц, а исследование Datos выявило, что 62 % десктопных устройств не посещают AI‑инструменты вовсе.

Эти цифры опровергают распространённый миф о том, что «все используют ИИ во всём». Большинство пользователей применяют его лишь изредко, а уровень недоверия растёт: Gallup отмечает рост «злобы» по отношению к ИИ на 40 % за год. По данным Searchlight Institute, 58 % американцев пробовали или используют ИИ, из них 30 % – регулярные (несколько раз в месяц) и 29 % – лишь раз в месяц или реже, что совпадает с результатами Microsoft и Datos. Исследование The Argument выявило, что большинство используют ИИ не чаще одного раза в неделю. Таким образом, реальная ситуация выглядит как «некоторые люди используют ИИ для некоторых задач», а не как всеобщее внедрение.

• Большинство интервьюers спрашивают, как вы используете LLM, но ответить сложно из‑за противоречивых интересов работодателей.
• В некоторых областях (например, в коде) LLM уже показывают большую ценность, в других — требуют тщательного контроля и часто оказываются разочаровывающими.
• Мнения разделяются: одни считают, что «все используют AI», другие указывают, что реальное внедрение пока ограничено и часто носит экспериментальный характер.
• Критики отмечают, что рост AI‑технологий часто мотивирован ленью и желанием ускорить процесс, а не качеством решения.

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

• Пользователи обсуждают, что код, сгенерированный LLM, часто выглядит правильным, но на практике требует переписывания, что перекладывает бремя на коллег-ревьюверов.
• Подчеркивается, что внедрение ИИ-инструментов часто сопровождается агрессивным продвижением, даже если это идет вразрез с продуктивностью и UX.
• Участники обсуждают, что вместо того, чтобы навязывать инструменты, компании должны инвестировать в обучение и поддержку разработчиков, чтобы они могли эффективно использовать ИИ.
• Поднимается вопрос, что если ИИ-инструменты действительно так эффективны, почему бы не сделать их использование добровольным, а не навязывать.
• Участники также обсуждают, что вместо того, чтобы требовать использование ИИ, компании должны сосредоточиться на создании культуры, где разработчики могли бы выбирать, какие инструменты использовать, включая ИИ, и где они могли бы расти.

В Cursor появились три ключевые функции для улучшения работы с ИИ-агентом. Автодополнение теперь предлагает подсказки на основе недавних изменений, ускоряя написание промптов. Хуки (в бета-версии) позволяют настраивать поведение агента через кастомные скрипты — например, для аудита использования, блокировки команд или скрытия секретов. Командные правила дают возможность устанавливать глобальные настройки через дашборд, обеспечивая единообразие во всех проектах, включая интеграцию с Bugbot.

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

• Пользователи отмечают снижение привлекательности Cursor из-за улучшения альтернатив (VSCode с Copilot, Claude Code) и проблем с ценовой политикой/стабильностью Cursor.
• Ключевым преимуществом Cursor считается удобное управление состоянием правок (чекпойнты, откаты) и, по мнению некоторых, лучшее автодополнение (Supermaven).
• Растёт интерес к использованию локальных моделей (LM Studio, Ollama) и CLI-инструментам (Claude Code) из-за проблем с квотами, стоимостью и стабильностью подключения в облачных решениях.
• Многие пользователи выражают недовольство стоимостью Cursor, сложностью отслеживания расходов и непредсказуемой скоростью ответа.
• Cursor позиционируется некоторыми как удобный «всё-в-одном» вариант для частого переключения моделей и параллельной работы нескольких агентов, но его долгосрочная актуальность ставится под сомнение.

Уязвимость Copilot: доступ к файлам без записи в журнал аудита
Автор: Zack Korman, 19.08.2025

Суть проблемы

M365 Copilot может читать файлы и не фиксировать это в журнале аудита, если попросить «не давать ссылку на файл». Это позволяет скрытно скачивать данные, нарушая безопасность и требования к соответствию.

Как обнаружил

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

Реакция Microsoft

• Уязвимость признали «важной» и исправили.
• Клиентов не уведомили; официального бюллетеня нет.
• Процесс MSRC занял 45 дней, ответы были формальными, без деталей.

Вывод

Журналы аудита M365 Copilot ненадёжны, а Microsoft не планирует информировать пользователей. Организациям стоит перепроверить свои логи и усилить контроль доступа к чувствительным данным.

• Copilot читает индексированные данные от имени привилегированного сервиса, поэтому не фиксирует в журнале доступ к самому файлу.
• Это приводит к утечкам: пользователь видит содержимое, но в аудите нет записи о нарушении прав.
• Исправление Microsoft ограничилось «автоматическим обновлением» без CVE и без изменения архитектуры.
• Участники считают проблему классической «confused deputy» и указывают, что фильтрация по правам в векторной БД вполне масштабируется.
• Советуют подключить Legal/Compliance и готовиться к регуляторным разбирательствам, особенно в HIPAA-окружении.