Hacker News Digest

Если вы пользуетесь большими языковыми моделями через готовый интерфейс с подпиской, вы видите лишь жалкое подобие статистики, а не данные, пригодные для инженерных решений. Автор настаивает: без собственного прокси-сервера вы просто не понимаете, что происходит с вашими запросами. Экспорт через OTel — лишь отговорка; настоящая прозрачность достигается только на своей инфраструктуре.

Свой прокси даёт единую точку для нескольких провайдеров и моделей, журналы того, какой ключ, какой клиент и в какое время вызывал какую модель и с каким статусом, а также виртуальные API-ключи вместо одного главного, который вы раскидываете по агентам и инструментам. Инфраструктура под вашим контролем позволяет мгновенно переключать модель или провайдера, не перенастраивая всё заново. Прокси можно дорабатывать под свои задачи — автор, например, добавил улучшенную аналитику и собственные конечные точки MCP.

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

Обсуждение дополняет статью альтернативами прокси-серверам (OTEL, локальные логи) и вопросом стоимости API по сравнению с подписками. Использование прокси критикуют как создание единой точки отказа (SPOF). @CharlieDigital предлагает более надежный и менее интрузивный OpenTelemetry (OTEL) для сбора трейсов. Для пользователей подписок @jakozaur рекомендует собирать структурированные JSONL-файлы из локальных директорий (например, ~/.claude/projects/). Стоимость API значительно выше подписок: по опыту @NeutralWanted, объем данных за лимит подписки Claude в $200/мес через API был бы исчерпан за 2–3 дня. Для корпораций подписки не подходят, так как Enterprise-планы OpenAI, Anthropic и GitHub Copilot стоят значительно дороже и не субсидируются (@Lucasoato). Для изоляции API-ключей в песочницах с агентами @hoppp использует LiteLLMProxy для выдачи виртуальных ключей и реализации guardrails. Однако @jubilanti считает LiteLLM и аналоги нестабильными и уязвимыми из-за частых обновлений. В качестве альтернатив прокси упоминаются Aperture от Tailscale, AgentsView для визуализации работы агентов и OpenRouter для управления запросами. Для полной прозрачности @voodooEntity и @joshheitzman рекомендуют создавать собственный каркас агента с детальным логированием и метриками в GUI.

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

За последние 25 лет благодаря целенаправленным усилиям правительства и коммунальных компаний потери сократились до 5–6 процентов к 2026 году — уровень, сравнимый с Францией и Бельгией, а надёжность сети выросла с 70 до 99,9 процента. Это достигнуто благодаря внедрению智能 счётчиков, аналитики и ИИ, но, как подчеркивает глава BSES Rajdhani Power, ключевую роль сыграли дисциплина исполнения, оперативная ответственность и вовлечённость потребителей. Теперь улицы освещены, электротранспорт растёт, а семьи живут без страха отключений. Однако в некоторых районах Дели и других индийских штатах потери остаются высокими из-за нелегальной зарядки эрикш, слабой цифровизации и проблем с оплатой — опыт Дели показывает, что технологии работают только в сочетании с жёстким исполнением правил.

Пользователи (@thumbsup-_-, @motionlessveloc и др.) подтверждают, что в начале 2000-х в Дели были ежедневные отключения, которые почти исчезли к середине десятилетия. Основными факторами стали приватизация сетей (Tata Power, BSES), модернизация инфраструктуры, борьба с кражами электроэнергии (составлявшими до 50 % потерь) и выравнивание финансовых стимулов. В ходе обсуждения возник спор о термине load shedding: @motionlessveloc считает его обозначением неплановых отключений, а @devnull3 — плановых. В качестве примеров и предложений привели следующее: — @truekonrads отметил опыт Эстонии, где умные счетчики обеспечили надежность сети 99,99 %. — @groos заметил, что изоляция линий для борьбы с кражами стала удобными «дорогами» для обезьян. — @thelastgallon предложил снизить зависимость от сети в закрытых комплексах через стандартизацию солнечных панелей, батарей, вертикальных установок и электрозарядок. — @0xWTF уточнил, использовались ли в реформах индийские трансформаторы и SCADA.

IBM Bob — это AI-ассистент для разработчиков, интегрированный непосредственно в среду разработки (IDE), который работает как партнёр в процессе создания ПО. Он поддерживает подход Literate Coding: разработчик описывает задачу на естественном языке, а Bob генерирует соответствующий код прямо в контексте проекта, устраняя необходимость переключаться между чат-окнами и редактором. Это ускоряет разработку и повышает качество кода за счёт контекстно-осознанных предложений.

Bob также предоставляет аналитику через Bobalytics — панель, отслеживающую вклад ИИ-агента в жизненный цикл поставки ПО на уровне всей организации. Это позволяет измерять бизнес-ценность использования ИИ, оптимизировать затраты и стимулировать внедрение агентных практик. Кроме того, Bob обеспечивает прямую интеграцию с Red Hat, Instana и другими корпоративными сервисами, bringing enterprise-grade архитектуру, безопасность и мониторинг прямо в IDE, что минимизирует переключение контекста и укрепляет DevOps-потоки.

Обсуждение скептичное: IBM Bob сравнивают с провальным Microsoft Bob 90-х, считая названием и подходом ностальгической насмешкой. Продукт воспринимается как переработанный Watson — повторение стратегии с отсутствием прозрачности, зависимостью от сторонних моделей и слабой интеграцией с реальными системами. Ценообразование в Bobcoins и мем-маркетинг (маскот, дизайн) читаются как несерьёзность и попытка скрыть слабость продукта. IBM не считается доверенным поставщиком на фоне истории с Watson и ухода от лидерства в ПО. Продукт ориентирован на менеджеров, а не инженеров — в обсуждении преобладают цитаты от руководства, а не разработчиков. Участники спорят, что Bob — обёртка над существующими моделями (Claude, OpenAI) без доказательств улучшенной интеграции с IBM i или z/OS, в отличие от конкурентов, уже обученных на этих системах. Часть участников считает, что Microsoft Bob не был ошибкой, а просто опередил время, но другие возражают: IBM повторяет ту же ошибку без учёта опыта. Советы: — Не называть продукты Bob в Великобритании — из-за сленга «bobbins» (чепуха) название обречено на насмешки, если продукт не идеален. — IBM стоит вернуться к созданию качественного ПО вместо продажи «агентских навыков» за $20/мес и опоры на консалтинг. — Разработчики не доверяют вендорам, контролирующим модели, — предпочтительнее открытые токены, чем закрытые «харнессы» под брендом IBM. Падение акций IBM на 20% за год отражает неверие рынка в подобные инициативы — Bob не решит системных проблем. Копирайтинг на сайте выглядит сгенерированным ИИ, что подрывает доверие даже при технической состоятельности продукта.