Hacker News Digest

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

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

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

Современные модели ИИ демонстрируют сверхчеловеческие способности в решении абстрактных задач, как показал недавний успех GPT-5 на ICPC, но автономные кодирующие агенты всё ещё не могут заменить разработчиков. Основное ограничение — не интеллект, а контекст: агентам не хватает глубокого понимания кодовой базы, её архитектурных паттернов и скрытых знаний, которые есть у людей.

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

• Основным ограничением для кодирующих агентов на основе ИИ является не размер контекстного окна, а неспособность эффективно фокусироваться на актуальных задачах и отбрасывать нерелевантную информацию.
• Многие участники отмечают, что ИИ-агенты демонстрируют уровень понимания, сравнимый с начинающим разработчиком, и не способны заменить senior-специалистов, которые могут интерпретировать бизнес-требования и принимать ответственные решения.
• Существует скептицизм относительно бесконечного увеличения "интеллекта" моделей, так как даже с большим контекстом они допускают ошибки и галлюцинации, а фундаментальные ограничения вероятностной генерации остаются.
• Предлагаются решения для улучшения работы агентов: лучше структурированные кодобазы, иерархическая документация, инструменты для управления контекстом и памятью, а также человеческий контроль для курирования процесса.
• Подчёркивается, что ключевая проблема — не технический контекст, а понимание intent (намерения) стоящего за кодом, что требует более глубокого осмысления, чем простое прогнозирование токенов.

Сейчас кодирующие агенты вроде Claude Code работают медленно и ненадёжно, напоминая dialup-модемы 90-х: частые сбои, необходимость перезапусков, скорость генерации всего 30-60 токенов в секунду. Это связано с взрывным ростом потребления токенов — по данным OpenRouter, объёмы выросли в 50 раз за короткий период, а агентные workflows требуют в 1000 раз больше ресурсов, чем обычные чаты.

Более высокая скорость, например 2000 токенов в секунду (как у Cerebras Code), кардинально меняет опыт: разработчик становится узким местом, а не модель. Это открывает путь к новому этапу — параллельным независящим агентам, которые предлагают несколько вариантов решения задачи с автоматической оценкой качества. Однако рост скорости лишь разгоняет спрос, создавая бесконечный цикл: чем лучше модели, тем сложнее задачи, которые мы им ставим.

• Скептицизм относительно реального повышения продуктивности из-за LLM: AI может создавать иллюзию продуктивности, снижая когнитивную вовлеченность и порождая проблемы с качеством и сопровождением кода.
• Ключевая проблема — скорость и контекст: Медленная генерация токенов и постоянное переключение контекста нарушают состояние потока (flow), а ограничения контекста приводят к ошибкам и галлюцинациям.
• Сдвиг роли разработчика: Инструмент меняет фокус с написания кода на проверку, редактирование и управление AI-агентами, что требует постоянной бдительности и новых навыков.
• Зависимость от надежности провайдеров: Сбои в работе AI-сервисов сравнимы с остановкой производства, что создает риски для рабочего процесса.
• Разные стратегии и предпочтения в использовании: Одни разработчики ценят интегрированные в IDE решения (Cursor), другие предпочитают сторонних агентов (Claude, Codex) или используют LLM как «калькулятор» для рутинных задач и обучения.