Hacker News Digest

С версии 0.157.0 CLI-инструмент Codex при простом запуске интерактивной сессии стал автоматически поднимать постоянный фоновый демон (codex app-server --managed-daemon). Он работает без TTY, переживает закрытие всех окон (переподчиняется процессу 1) и завершается только командой остановки или перезагрузкой. Автор предлагает сделать daemon_auto_start опциональным (по умолчанию false) либо хотя бы один раз спрашивать согласие.

Демон копирует весь платформенный пакет (~374 МБ: codex, codex-code-mode-host, встроенные bwrap/zsh/rg) в ~/.codex/packages/app-server-daemon/releases/<версия>/ и запускается из копии, из-за чего версия бэкенда расходится с установленной через пакетный менеджер. Отдельный самообновляющийся процесс (pid-update-loop) проверяет обновления через 5 минут, затем ежечасно, скачивает новые релизы и перезапускает бэкенд, что может убивать активные сессии. Демон также «закрепляет» окружение первой сессии: например, переменные HTTPS_PROXY остаются от того запуска, который его стартовал, независимо от параметров последующих сессий.

Для CLI ожидаемо, чтобы бэкенд жил и умирал вместе с окном, запускал установленный бинарник и не обновлялся сам. Если поведение оставят по умолчанию, автор просит завершать демон при отключении последнего клиента и не копировать/самообновляться при установке через npm/brew/pacman. Обнаружен и баг: daemon stop останавливает app-server, но оставляет pid-update-loop живым. Обходной путь — отключить функцию, остановить демон, вручную убить процесс обновления и удалить каталог пакета.

Автозапуск демона Codex CLI вызывает проблемы: баги, переполнение диска (до 12 ГБ в ~/.codex), нарушение прав доступа (например, .git становится доступен только для чтения) и блокировку выполнения целей. Демон работает независимо от TTY и не наследует переменные окружения шелла, что ломает автоматизацию. Некоторые пользователи считают такой скрытый процесс небезопасным и сравнивают его с «бекдором». Способы решения: 1. Отключить автозапуск в ~/.codex/config.toml: `[features] daemon_auto_start = false`. 2. Использовать флаг `--no-daemon`. 3. Полностью заблокировать демон, заменив pid- и lock-файлы ссылками на /dev/null с командой `chattr +i`. 4. Перейти на минимальные инструменты (hax) или изолировать Codex в Docker-контейнере с фиксированными версиями. Мнения об автообновлениях разделились: одни считают их стандартной практикой, другие — опасными и враждебными к пользователю.

Docker Agent — это CLI-плагин для Docker, позволяющий создавать и запускать ИИ-агентов через декларативный YAML-конфиг без написания кода. Агенты могут использовать инструменты, взаимодействовать с различными LLM-провайдерами (OpenAI, Anthropic, Gemini, AWS Bedrock и др.) и работать в режиме мультиагентного взаимодействия, делегируя задачи между собой. Поддерживается RAG, встроенные инструменты для мышления и памяти, а также интеграция с MCP-серверами (локальными, удалёнными или на базе Docker). Конфигурация агента описывает модель, инструкции и наборы инструментов — например, доступ к DuckDuckGo через MCP.

Установка проста: в Docker Desktop 4.63+ плагин уже включён и доступен через docker agent; также можно установить через Homebrew или загрузить бинарник с GitHub Releases. Для работы требуется API-ключ от поддерживаемого провайдера или использование Docker Model Runner для локальных моделей. Запуск агента выполняется командой docker agent run agent.yaml, а готовые агенты можно упаковывать в OCI-образы, публиковать в реестрах и запускать везде, где есть Docker. Инструмент позиционируется как способ сделать ИИ-агентов портативными, версионируемыми и совместными — как обычные контейнеры.

Docker Agent воспринимается как экспериментальный и нестабильный инструмент, не готовый к продакшену из-за отсутствия безопасности, документации и четких сценариев применения. Пользователи считают проект «gimmick», который дублирует функции аналогов (kagent, LangChain, Cloudflare Sandboxes) и не дает реальных преимуществ. Основные проблемы и споры: — Обещание «no code» считается излишним, так как современные LLM уже генерируют готовый код. — Среди критических вызовов выделяют как поддержание когерентности агентов, так и проблемы масштабирования и маршрутизации. — Новым пользователям сложно начать работу из-за нехватки практических примеров и руководств. Рекомендации: — Внедрить явный механизм песочницы, ACL-подобные ограничения на команды и сетевые данные с возможностью запроса дополнительных прав. — Создать управляемый облачный сервис для запуска YAML-агентов в изолированных средах без локальной установки Docker. — Четко описать целевые сценарии использования, чтобы отличить продукт от других агентских проектов.

Reladraw — это текстовый язык для создания диаграмм с точным, но гибким позиционированием элементов. В отличие от Mermaid или Graphviz, где расположение автоматизировано, и draw.io, где нужно вручную перетаскивать узлы, Reladraw позволяет задавать относительные позиции: below, right of, level with — без ручного указания координат. Например, диаграмма архитектуры из 10 узлов и связей описывается всего 7 строками кода, что делает её легко редактируемой и версионируемой. Результат рендерится в SVG без внешних зависимостей.

Инструмент доступен как CLI-утилита через npm install -g reladraw и интегрируется с AI-агентами (Claude, Copilot и др.) через плагины. На данный момент версия 0.11.1 — ранняя, с нестабильным синтаксисом, но уже работает: парсер, движок макета и рендерер написаны на TypeScript. Проект открыт для обратной связи — особенно ценятся примеры диаграмм, которые невозможно выразить текущим синтаксисом. Лицензия Apache-2.0, но торговая марка «reladraw» не включена в разрешения.

Обсуждение подтверждает, что необходимость точного позиционирования в диаграммах действительно существует и Reladraw закрывает этот пробел, однако пользователи указывают на баги (тёмные темы, кривые стрелки), просят интеграцию в markdown и IDE, а также сравнивают его с D2/TALA и задаются вопросом, стоит ли создавать новый язык или расширять существующие инструменты вроде Mermaid.

• Большинство комментаторов считают, что текущие инструменты (Mermaid, Graphviz, draw.io) либо автоматизируют расположение, либо требуют ручного перетаскивания, и поэтому им не хватает детального контроля, который предоставляет Reladraw.

• Относительные позиции (below, right of, level with) воспринимаются как достаточный уровень точности для большинства диаграмм, избавляя от необходимости указывать абсолютные координаты.

• Совет: Разработчикам рекомендуется создать плагины для популярных редакторов (VS Code, Obsidian) и поддержать блоки кода ```reladraw в markdown, чтобы упростить использование в документации.

• Совет: Полезно отделить топологическую часть языка (стрелки, группы) от инструкций по расположению, что позволит использовать Reladraw как слой раскладки для других DSL, например C43.

• В обсуждении отмечены баги: некорректный рендер кривой стрелки при указании from/to и проблемы с переключением тем в Safari, где тёмный фон делает текст нечитаемым.

• Совет: Необходимо добавить поддержку тем и исправить рендеринг в разных браузерах, а также обеспечить более стабильный веб‐интерфейс перед выпуском.

• Некоторые пользователи упомянули D2 с открытым движком TALA, который уже предоставляет ручной контроль над расположением и иногда генерирует более качественные макеты, чем Mermaid.

• Спор: Одна сторона считает, что вместо создания нового языка следует добавить ограничения размещения в Mermaid, чтобы не фрагментировать экосистему; другая сторона аргументирует, что только отдельный язык может гарантировать детерминированный результат без вмешательства движка раскладки.

• Есть интерес к автоматическому преобразованию описаний архитектуры, сказанных устно, в Reladraw‐диаграммы, что может облегчить взаимодействие с AI‐агентами.

• Совет: Рассмотреть возможность импорта/экспорта из/в форматы draw.io, чтобы пользователи могли мигрировать существующие схемы в Reladraw без потери информации.

This is very needed in the AI coding age! I find diagramming is one of the best ways for high bandwidth alignment between my mental model and the agent’s. I have been working on this problem a bit as I see good visuals as a key bottleneck in faster development while maintaining a real… — @apinstein

Git-bug — это распределённый трекер ошибок, полностью интегрированный в Git: он хранит данные внутри репозитория, не добавляя файлов в проект, и позволяет работать офлайн, синхронно с кодом через обычные команды git bug push и git bug pull. Благодаря этому ваш трекер ошибок всегда доступен, даже без интернета или при недоступности внешних сервисов, и не привязывает вас к конкретному провайдеру — вы получаете полную резервную копию вместе с кодом.

Инструмент поддерживает несколько workflow: нативный (синхронизация через Git remotes), bridge-режим (импорт/экспорт с другими трекерами вроде Jira или GitHub Issues) и экспериментальный веб-интерфейс. Управление происходит через CLI: создание багов (git bug add), фильтрация по запросам (git bug ls "status:open"), интерактивный терминальный UI (git bug termui) и GraphQL API для интеграции с внешними инструментами. Все операции быстрые, не загрязняют рабочее дерево и сохраняют полную историю изменений вместе с коммитами. Лицензия — GPLv3.

Git-bug изолирует трекер ошибок от кода, но требует упрощения интерфейса для нетехнических пользователей и решения конфликтов идентичностей при офлайн-синхронизации. Для монетизации нужно снизить барьер входа, так как Git-интеграция уменьшает доступность по сравнению с GitHub или Jira. Рекомендуется интегрировать ForgeFed или IndieAuth для децентрализованной аутентификации, избегая привязки к централизованным провайдерам. Использование DID:PLC (как в Bluesky) упростит перенос идентификаторов между репозиториями — критично для распределённой модели. Некоторые считают, что трекер ошибок не должен быть частью репозитория: достаточно хранить баги в отдельной ветке или в SQLite (как @0xbadcafebee). Git-bug эффективен для маленьких команд, где минимизация переключения контекста между кодом и трекером повышает продуктивность (по @michaelastreiko). Проблема дублирования багов при офлайн-работе требует механизма слияния, аналогичного git-слиянию — это не решено в текущей реализации (по @promptsphereeee). Имя 'git-bug' ограничивает применение для отслеживания фич — возможно, стоит переименовать или расширить функционал (по @bflesch). Для привлечения пользователей важно поддерживать WebUI с OAuth, но также обеспечить работу без веб-интерфейса (как b4 и cgit на kernel.org, по @Aissen). Git-bug — часть тренда локально-первичных инструментов (как Fossil, ticgit, git-issue), но его успех зависит от устранения барьеров ввода и синхронизации (по @Izkata и @khimaros). Разделение трекера и кода через отдельную ветку (например, issues-branch) даёт гибкость и изолирует изменения (по @0xbadcafebee), что проще для масштабирования. Некоторые сомневаются в необходимости Git-bug, так как GitHub Issues уже интегрирован с Git и работает для большинства команд (по @Alex131313 и @zeroq). Использование git-refs для хранения багов (как в gitseq от @inguz) позволяет сохранять подпись и последовательность — потенциально более надёжно, чем текущий подход git-bug.

Дэвид Хайнемайер Ханссон объявил, что отошёл от профессионального программирования и теперь позиционирует себя как «мейкер», веря, что английский язык стал лучшим языком программирования благодаря LLM, а чтение сгенерированного кода больше не требуется. Он утверждает, что ручное написание кода перестало быть экономически продуктивным для большинства программистов, и что 37signals переписывают Hey на нативные приложения с использованием Rust на серверной стороне — языка, который он считает «ужасным» для людей, но идеальным для LLM, поскольку он не читает код anyway. За август он насгенерировал 150 тыс. строк кода (в основном «словного» Rust), тогда как раньше писал около 30 тыс. в год, и доля Ruby в его работе упала с 50% до 3%. Его видение: к концу года LLMs будут доминировать во всех сферах, а люди будут читать код лишь исключительно, как ошибку в Sentry. Он также хочет, чтобы у каждого сервиса был CLI для взаимодействия через агентов. На Rails World 2026 он использовал ключевую речь, чтобы объявить, что флагманское Rails-приложение Hey покидает фреймворк, хотя и отметил, что Rails остаётся хорошим для веб-приложений и разработки с ИИ. Однако его аргументы сводились к тому, что Rails был лишь временным обходным манёвром, а теперь его роль сведена к «веб-приложениям по необходимости», а «конвенция над конфигурацией» переосмыслена как «эффективность токенов». Критик отмечает отсутствие чёткой стратегии для Rails, заменённую оптимизмом без фактической основы, и выражает разочарование тем, что вместо обсуждения будущего Rails DHH предложил лишь веру в ИИ и отверг скептицизм как «чёрную таблетку для неудачников».

Rails не умирает из-за технологий, а из-за ухода DHH. Многие разработчики продолжают использовать его для CRUD- и LoB-приложений в 2026 году благодаря сильным конвенциям, упрощающим поддержку, даже если LLM генерирует большую часть кода. LLM-генерация делает производительность Ruby менее критичной, так как разработчики фокусируются на проверке и доработке сгенерированного кода. Один разработчик отмечает, что 90% его 25k строк продакшн-кода и тестов генерируются LLM — код надежен, легко расширяем и требует меньшего ручного вмешательства. SRE предупреждают, что если LLM генерирует код быстрее, чем человек его читает, чтение становится необязательным, что ставит под вопрос понимание системы на уровне инженеров. Производительность Rails (80–100 мс на запрос) остаётся приемлемой для большинства бизнес-приложений, и миграция не мотивирована скоростью, а удобством разработки. Компании не переходят на другие стеки из-за производительности, а из-за усталости от устаревших инструментов и отсутствия развития экосистемы без DHH. Критики утверждают, что DHH, как BDFL, не передал управление, что привело к фрагментации сообщества и необходимости форка — это системная проблема, а не техническая. Некоторые считают, что переход на нативные приложения или CLI-агенты — ответ на ограничения веб-фиделити, а не на устаревание Rails. LLM не генерируют код в WASM или нативной сборке, а используют высокоуровневые языки, значит, они ускоряют разработку фреймворков, а не заменяют их. Исторически Rails решал проблему медленной разработки в 2000-х — теперь эта проблема решена LLM, и фреймворки перестают быть конкурентным преимуществом, а становятся инструментом. Разработчики, ушедшие от Ruby, рекомендуют Kotlin+http4k как альтернативу: он сохраняет стиль Ruby с типизацией, поддерживает функциональный подход и лучше интегрируется с агентными системами.

MCP (Model Context Protocol) был создан Anthropic в ноябре 2024 года как способ подключения ИИ-агентов к внешним сервисам и данным, когда модели ещё не могли надёжно работать с API напрямую. Протокол быстро набрал популярность, но привёл к контекстному перегрузу: каждый MCP-сервер добавлял множество инструментов со своими схемами, перегружая контекст моделей. Для обхода этой проблемы появились обёртки вроде Composio и MintMCP, которые централизуют учётные данные и дают агентам минимальный набор инструментов — полезное краткосрочное решение.

Однако модели значительно улучшились: теперь они способны писать и выполнять скрипты, вызывать незнакомые API, использовать CLI через --help и работать автономно. Это делает MCP излишним — агенты с доступом к терминалу могут напрямую взаимодействовать с сервисами через HTTP и CLI, минуя промежуточный слой. Автор предлагает прекратить поддержку MCP и перейти на прямое использование существующих интерфейсов, поскольку протокол устарел вместе с ростом возможностей ИИ.

MCP стал критически важным для безопасного, аудитируемого и управляемого доступа ИИ-агентов к сервисам без прямого доступа к API или терминалу, особенно в корпоративной и непрограммистской среде. Он позволяет контролировать, какие внешние сервисы может использовать агент, и изолировать API-ключи от модели, что критично для безопасности. MCP-плагины в ChatGPT и позволяют бизнес-пользователям без технического бэкграунда подключать сервисы одним кликом, делая их основным каналом взаимодействия с ИИ. MCP обеспечивает единый протокол для доступа к HTTP-сервисам и локальным процессам через stdin, что делает его гибче, чем CLI или прямые API. Многие компании, не имевшие API, теперь предоставляют MCP-серверы, чтобы дать пользователям доступ к данным через агентов — это выгодный сдвиг в сторону открытости. MCP позволяет агентам использовать новые функции сервиса сразу после обновления сервера, без переобучения модели, решая проблему устаревания контекста. Для агентов без доступа к терминалу (например, в облачных, мобильных или iPhone-средах) MCP — единственный практичный способ взаимодействия с внутренними системами. MCP-серверы могут включать трансформации и фильтрации данных, которые API не поддерживают, обеспечивая безопасный и релевантный доступ к чувствительной информации. Они также поддерживают автоматическое обновление регистраций, снижая административную нагрузку при масштабировании. MCP позволяет агентам работать с UI-приложениями (например, Unity, Blender), которые не имеют API, предоставляя скриптируемый интерфейс через сокет. Споры о избыточности MCP игнорируют случаи, где прямой доступ запрещён политиками безопасности или отсутствует. Критика о перегрузке контекста неверна: в реальных сценариях включаются только релевантные серверы. Рекомендуется развивать специализированные CLI для агентов (например, grafana/gcx), стандартизировать HTTP-заголовки для ответов в Markdown или упрощённом JSON, и использовать MCP как основу для протоколов вроде ADP (Agent Delegation Protocol). Ничего не добавлять от себя.

Tailcat — это утилита от Tailscale, которая позволяет устанавливать зашифрованные соединения между машинами по принципу netcat, но используя только данные плоскости Tailscale (magicsock и DERP), минуя её контрольную плоскость. Это означает, что для работы не нужен аккаунт Tailscale, root-доступ или изменение системных настроек — всё работает в пользовательском пространстве. Трафик шифруется end-to-end через WireGuard, а начальное соединение устанавливается через DERP-релеи (по умолчанию — бесплатные, rate-limited от Tailscale), после чего magicsock пытается перейти на прямое P2P UDP-соединение, если NAT позволяет.

Один запуск tailcat на сервере генерирует одноразовый токен подключения, который клиент использует для установки канала. После этого можно передавать stdin/stdout, пробрасывать локальные TCP-порты (например, --serve=8080) или даже запускать auth-free SSH-сервер через --serve=no-auth-ssh. Утилита также поддерживает пинг с указанием пути (DERP или прямой) и флагом --until-direct для ожидания оптимального маршрута. Проект полностью open source, но без гарантий стабильности API, CLI или работы публичных DERP-релеев — всё предоставляется «как есть». Tailcat возник как эксперимент «derpcat» в 2023 году, был выделен в отдельный модуль и открыт в августе 2026 на конференции TailscaleUp.

**Tailcat** Tailcat — практическое воплощение принципа end-to-end connectivity: использует инфраструктуру Tailscale (magicsock, DERP) без зависимости от её control plane, что позволяет устанавливать P2P-соединения без root-доступа и аккаунтов. Механизм: односторонний обмен ключами через Meow-сообщения по DERP, затем стандартный CallMeMaybe для прямого соединения — полноценная интеграция с внутренними механизмами Tailscale, а не просто обёртка. **Инфраструктура и ограничения** Tailscale сознательно выделил отдельные DERP-серверы для публичного использования с ограничением скорости, чтобы поддерживать открытость без влияния на основную инфраструктуру (Brad Fitzpatrick). Этот rate-limit также ограничивает пригодность Tailcat для C2-каналов (@MajesticHobo2). **Практические сценарии** Tailcat работает в пользовательском пространстве и не требует root-доступа, что делает его удобным для CI/CD, облачных VM и ограниченных систем. Решает проблему P2P-соединений без настройки портов и NAT — особенно ценно в условиях CGNAT и ограниченного IPv6 (@pbohun). Примеры применения: Minecraft-моды, SSH-серверы на systemd, замена WebSocket-прокси в Mosh для прямой работы с UDP-трафиком (@ekarulf). Nix-окружение в репозитории отражает внутреннюю практику Tailscale, где Nix — стандарт разработки, а не опциональный инструмент (@ronef). **Сравнение с аналогами** Tailcat напоминает Magic Wormhole, но расширяет идею с передачи файлов на произвольные TCP-соединения, сохраняя простоту, но без human-readable session IDs (@doomrobo). Среди аналогов — Wush и Iroh, использующие Tailscale или WireGuard; Tailcat выделяется простотой и прямой интеграцией с magicsock без дополнительных зависимостей. **Споры и альтернативы** Часть пользователей (@gz5) считает, что Tailcat недостаточно радикален: если цель — устранить проприетарность, нужно полностью отказаться от Tailscale DERP, как в NetBird, ZeroTier или OpenZiti. Другие (@LarsKrimi) сомневаются в надёжности самого Tailscale, хотя это не опровергает работоспособность Tailcat. Альтернатива от @maisem: запуск кастомного клиента Tailscale, подключающегося к двум tailnet одновременно (tailmix), решает проблему доступа к домашней сети из офисной без Tailcat. **Документация и принцип** Различие control/data plane в официальной документации Tailscale помогло разобраться в архитектуре (@forrestthewoods) — важность документации для новичков подтверждается. Идея Tailcat соответствует end-to-end принципу (@MajesticHobo2): интернет не должен предоставлять встроенные механизмы для NAT, шифрования или идентификации — эти функции должно приносить приложение.

Код теперь можно размещать напрямую в Cursor через новую функцию Origin — early‑beta‑режим для платных пользователей. В появившемся Codebase‑разделе можно создать репозиторий, задать ему название (URL будет выглядеть как cursor.com/codebase/название), установить CLI и начать пушить локальный проект. Синхронизация с GitHub позволяет держать репозитории как на GitHub, так и в Origin, при этом выбирая, какие из них синхронизировать, и отключать их в любой момент.

Pull‑requests работают в обе стороны: комментарии и реакции в Cursor мгновенно отражаются в GitHub и обратно. В каждом репозитории доступны встроенные агенты, которые могут отвечать на вопросы о коде, менять PR‑ы и пушить ветки. Интеграции с Vercel, Depot и Buildkite уже готовы: через Apps‑таб можно привязать Vercel для preview‑деплоя каждого PR, а Depot и Buildkite — для запуска CI‑pipeline, включая GitHub Actions. Настройки репозитория позволяют проверять статус синхронизации, управлять доступом и подключать приложения.

Запомните: название репозитория становится частью URL, а синхронизация происходит в реальном времени, сохраняя GitHub как источник истины. Сейчас Origin доступен в early‑beta для всех платных планов, кроме компаний, которые явно отключили его. Начать работу можно сразу в интерфейсе Cursor.

Пользователи отвергают Origin как GitHub-альтернативу из-за связи с Илоном Маском и опасений, что код будет использоваться для обучения Grok. Предпочтение отдается децентрализованным решениям (Radicle, Forgejo, SourceHut, Codeberg, Tangled) или self-hosted Git — как более безопасным для приватности. Origin ограничен синхронизацией с GitHub и не предлагает инноваций в агентных рабочих процессах, что вызывает критику как «GitHub clone». Технические недостатки — высокий расход CPU и требование SMS-верификации — снижают доверие. Споры идут о природе рисков: одни считают проблему в росте кода из-за AI, другие — в принудительном сборе данных Cursor для обучения моделей. Эксперты полагают, что Cursor ориентирован не на хостинг, а на сбор истории версий и патчей для AI.

Qwen3.8-Max — новый флагман серии Qwen, впервые открывающий веса модели уровня Max (2,4 трлн параметров, из которых 95 млрд активно используются). Основное новшество — способность самостоятельно реализовывать сложные, длительные задачи: от создания полноценного CLI‑утилита с автогенерируемым механизмом обратной связи до многократного улучшения собственного тест‑пакета без вмешательства человека. В тестах модель прошла 10‑дневный автономный цикл, где её агент формировал задачи в GitHub Issues, выбирал их, писал код, запускал CI, сливал PR и даже улучшал процесс тестирования на основе результатов. Такой «loop‑engineering» позволяет модели не просто выполнять сценарии, а адаптировать их под текущие ограничения, что делает её результаты более надёжными и воспроизводимыми.

Ключевые цифры: 2,4 трлн параметров, 95 млрд активных, 10+ дней непрерывного кодинга без человеческого контроля, публичный репозиторий [qwen-code-dev-bot/oh‑my‑cli] с полной историей изменений. Открытие весов запланировано на следующую неделю, что откроет доступ к этим возможностям шире.

Qwen3.8-27B может быть более эффективным, чем Qwen3.6-27B и Qwen3.5, а также чем KimiK3-Thinking. Qwen3.8-Max показывает лучшие результаты в визуальном веб-разработке и перцепшенбенче, имеет 2,4 трлн параметров и может быть слишком большим или сложным для использования на домашних компьютерах. Qwen3.6-35B-A3B подходит для задач Python и баз данных. Некоторые считают, что Qwen3.6 модели эффективны для домашнего использования. Qwen3.8-Max может иметь более низкую стоимость, чем Deepseek. Alibaba Cloud может создавать излишние барьеры для домашнего использования. Если LLM не может запоминать и учиться, его легко заменить — это означает, что AI-компании не обладают монопольным положением на рынке.

Stateless MCP 2.0 — выпущенный 28 июля 2026 года — вернул интерес к протоколу, упростив его до одной HTTP-запроса без сессий. Ранее требовалось два запроса: инициализация сессии и вызов инструмента, теперь всё передаётся в одном запросе через заголовки MCP-Protocol-Version, Mcp-Method и Mcp-Name, а метаданные клиента включаются в _meta. Это устраняет необходимость хранить состояние на сервере, делая систему масштабируемой и проще для реализации — автор построил три реализации за неделю.

Вдохновлённый упрощением, он создал mcp-explorer — CLI-инструмент, позволяющий через uvx mcp мгновенно тестировать MCP-серверы. Пример: запрос «count the notes» к Datasette вернул 151 заметку, с детальным логом рассуждений LLM. MCP теперь выглядит безопаснее, чем доступ к терминалу и curl: он ограничивает возможности агента заранее аудитируемыми действиями, снижая риски утечек данных и атак типа «смертельной триады». Автор планирует активно использовать MCP в чувствительных приложениях, где безопасность важнее гибкости.

Тред дополняет статью опытом эксплуатации MCP, возражениями, предложениями по улучшению и обсуждением ограничений текущей реализации. @rutierut отмечает, что навыки не загрязняют контекстное окно и гибче, но это не универсально. @ai_critic считает MCP просто RPC-over-HTTP/JSON, @lexicality — что стандартизация взаимодействия со сервисами — верный подход. @mailmrg предлагает использовать generic HTTP execution engine и YAML-описания endpoint’ов для решения проблем. @mmasu подчеркивает, что MCP даёт доступ к ресурсам, недоступным через API или CLI. @cush утверждает, что MCP менее составен, чем CLI, и может загрязнять контекст; @olmo23 отвечает, что это можно компенсировать позволением AI оценивать код и предоставляя нужные API.

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

Создавать и управлять стеками можно через GitHub CLI или веб-интерфейс: команда gh extension install github/gh-stack позволяет начать за минуту. Все проверки, защиты веток и требования к слиянию работают без изменений. Можно слить весь стек одним кликом или частично — нижние уровни автоматически переадресуются на верхние. Разработчики из Vercel и WHOOP отмечают, что стеки сделали процесс ревью прозрачным, а слияние — быстрым и безопасным. Поддержка очередей слияний будет внедрена в ближайшие недели.

Тред обсуждает новую функцию GitHub — стековые пул-реквесты: некоторые пользователи считают её полезной для крупных и сложных проектов с множеством зависимостей, так как она упрощает проверку и слияние изменений. Другие выражают сомнения, указывая на риски длинных веток и необходимость повторного утверждения. Эксперты рекомендуют применять функцию в сочетании с другими инструментами, например jj, для оптимального результата.

Инструмент @openai/codex-security — это CLI и TypeScript‑SDK, позволяющие обнаруживать, проверять и исправлять уязвимости в коде. Требуется Node 22 или новее и Python 3.10 +, а также доступ к Codex Security. Установка через npm i @openai/codex-security, вход командой npx codex-security login и сканирование репозитория npx codex-security scan .. Для CI можно использовать переменную OPENAI_API_KEY вместо входа, а при наличии обоих учетных записей интерактивный скан запрашивает выбранный метод; в неинтерактивных режимах приоритет остаётся у API‑ключа. Параметр --auth chatgpt или --auth api-key позволяет явно указать источник.

Результаты сканирования сохраняются в рабочем каталоге Codex Security; если запись недоступна, задайте CODEX_SECURITY_STATE_DIR на записываемую директорию. Для работы с TypeScript‑SDK импортируют CodexSecurity из пакета, создают экземпляр, вызывают run('.'), выводят reportPath и закрывают соединение close(). Всё необходимое о параметрах сканирования, настройке CI и дополнительных опциях описано в официальной документации. Интересный факт: при конфликте учётных данных интерактивный режим предлагает выбрать источник, а в автоматизированных пайплайнах предпочтение отдаётся API‑ключу, что упрощает интеграцию в существующие workflow. Кроме того, можно фильтровать результаты по уровню угрозы через --severity и экспортировать отчёт в JSON для дальнейшего анализа.

Тред обсуждает практический опыт использования Codex Security: пользователи отмечают высокие затраты и ограничения по скорости запросов, что может быть проблемой для крупных проектов. Есть споры о его эффективности — одни считают инструмент полезным для обнаружения уязвимостей, другие сомневаются в его способностях. Рекомендуется использовать опцию --max-cost для контроля расходов. Codex Security сравнивают с Snyk и Strix, обсуждая его потенциальное влияние на рынок безопасности.

Два месяца назад меня уволили из Google за разработку Google Workspace CLI, проекта, который мгновенно стал вирусным: он занял первое место в Hacker News, набрал тысячи звёзд на GitHub и привлек десятки тысяч реальных пользователей за пару дней. Среди реакций — вопросы руководства о том, что они могут извлечь из инструмента, и проверка юридическим отделом из‑за использования логотипа и фирменных цветов в репозитории. Я считаю, что причина ухода не в конкретном CLI, а в более широкой тревоге по поводу возможного разрушения текущих процессов Workspace. Ирония усилилась тем, что за два дня до моего увольнения Google объявила о выпуске официального Workspace CLI на конференции Cloud Next.

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

• Уволенный сотрудник Google создал CLI‑утилиту, имитирующую официальное продуктное предложение, что нарушило бренд‑правила компании.
• Комментаторы обсуждают, что подобные проекты часто разрешяются в рамках 20 % времени, но здесь произошёл конфликт с внутренними процедурами и логотипами.
• Мнения разделяются: одни считают увольнение оправданным из‑за риска для репутации Google, другие видят в этом подавление инициатив и потерю таланта.
• Обсуждение поднимает вопросы о гибкости корпоративных правил, возможности официально интегрировать такие проекты и последствиях для морального климата в крупных технологических компаниях.

Автор случайно обнаружил lazygit во время экспериментов с neovim и настолько впечатлился, что полностью перешёл на него для всех git-работ. Инструмент сочетает простоту и скорость CLI с интерактивностью и наглядностью GUI, что особенно ценно для тех, кто плохо запоминает команды. По данным опроса StackOverflow 2022 года, 83% разработчиков предпочитают CLI для работы с git, но lazygit предлагает компромисс, сохраняя мощь командной строки while делая операции более доступными.

Lazygit выделяется тремя ключевыми особенностями: последовательность интерфейса, удобство навигации и интерактивность. Автор подчёркивает, что несмотря на преимущества GUI, новичкам всё равно следует изучать git CLI, так как он обеспечивает максимальный контроль и необходим для работы в средах без графического интерфейса. Инструмент идеально подходит для разработчиков, ищущих баланс между мощью командной строки и удобством визуального интерфейса.

• Разные инструменты подходят под разные задачи: от легковесных консольных утилит вроде tig до полноценных GUI вроде SourceTree или GitKraken.
• Некоторые участники отдают предпочтение TUI-решениям вроде lazygit, другие — полноценным GUI, а кто-то вовсе предпочитает консоль.
• Несколько человек упомянули, что используют jj (Jujutsu) вместо Git, и что это может быть более удобным для новичков.
• Некоторые участники поделились ссылками на инструменты, которые могут быть полезны для решения конкретных задач, таких как git-absorb для автоматического разбиения коммитов и tig для просмотра истории.
• Были упомянуты такие инструменты, как lazygit, tig, gitui, gitin, lazygit, fork, lazygit и gitui, каждый из которых имеет свои сильные стороны и может быть полезен в различных ситуациях.

Автор активно использует Claude Code как для хобби-проектов, так и профессионально, где его команда потребляет несколько миллиардов токенов в месяц для генерации кода. По его мнению, пространство CLI-агентов стало конкурентным полем, но выбор разработчиков часто зависит от поверхностных различий в реализации функций или "тона" системных промптов, а не от фундаментальных различий. Автор предпочитает подход "забыл и забыл" — делегировать задачи, задавать контекст и позволять ИИ работать, оценивая результат по финальному PR, а не по процессу.

Ключевым элементом эффективного использования Claude Code является файл CLAUDE.md в корне репозитория, который служит "конституцией" для агента. В профессиональной среде этот файл строго поддерживается и достигает 13 КБ, потенциально вырастая до 25 КБ. Автор рекомендует начинать с ограничений, а не с полного руководства, избегать встраивания полного документации в контекст, не просто говорить "никогда", а предлагать альтернативы, и использовать CLAUDE.md как инструмент для упрощения внутреннего инструментария. Для совместимости с другими AI-IDE файл синхронизируется с AGENTS.md.

• Обсуждение охватывает вопросы от синхронизации файлов агентов (AGENTS.md ↔ CLAUDE.md) до философии MCP и навыков (skills), а также затрагивает рабочий процесс с git-worktree и CLI-утилитами.
• Участники обмениваются опытом использования Claude Code, Cursor и других инструментов, обсуждают их преимущества и недостатки, а также их влияние на разработку и рабочий процесс.
• Обсуждаются проблемы с контекстом, который может использовать агент, и как лучше всего структурировать проекты для облегчения работы агента.
• Также затрагивается вопрос о том, как лучше всего использовать инструменты в зависимости от ситуации и как они могут быть улучшены.

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

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

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

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

Краткий пересказ:
lavandula — это минималистичный веб-фреймворк на C, который обещает «скорость C и удобство Python». Проект с открытым исходным кодом, лицензия MIT. Сейчас он находится в стадии альфа-тестирования: базовый роутинг, middleware, JSON-ответы и простой шаблонизатор уже работают. Пример «Hello, world» компилируется в 12 КБ статического бинарника, а полноценный REST API сервис — меньше 100 КБ.

Планы: добавить встроенный ORM, WebSocket и SSE, а также CLI-генератор проектов. Поддержка Windows пока нестабильна, но Linux и macOS уже можно использовать. Сообщество приветствует вклад: обсуждение ведётся в Discussions, а примеры кода и бенчмарки публикуются в репозитории.

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

Предлагается добавить в Python явный синтаксис для ленивого импорта с ключевым словом lazy, которое размещается перед import или from. Это позволяет отложить загрузку модуля до момента первого использования импортированного имени, сокращая время запуска и потребление памяти. Особенно полезно для CLI-инструментов с подкомандами, где даже вызов --help может загружать десятки ненужных модулей.

Ленивые импорты сохраняют полную обратную совместимость — обычные импорты работают как раньше, а новые семантика активируется только при явном указании. Механизм использует прокси-объекты, которые заменяются реальными значениями при первом обращении (реификация). Это решает проблему ручного переноса импортов в функции, что уже делается в 17% случаев в стандартной библиотеке.

• Предложение о ленивых импортах (PEP 690) поддерживается для ускорения запуска CLI-инструментов и уменьшения накладных расходов, но вызывает опасения по поводу непредсказуемости и ошибок времени выполнения.
• Критики указывают на проблемы с безопасностью потоков, сложность отладки и потенциальное ухудшение читаемости кода из-за нового синтаксиса (lazy import).
• Альтернативы включают ленивую загрузку на уровне модуля (с явным объявлением модулем), использование существующих методов (импорт внутри функций) или инструментов вроде LazyLoader.
• Некоторые участники выступают за ленивые импорты по умолчанию, но признают, что это нарушит обратную совместимость из-за побочных эффектов при импорте.
• Обсуждаются вопросы совместимости с линтерами, влияние на стандартную библиотеку и необходимость обновления парсеров и редакторов для поддержки нового ключевого слова.

Claude Code превратился из инструмента для помощи в программировании в полноценную операционную систему с агентным подходом, интегрирующуюся с Obsidian через доступ к файловой системе. Ключевое преимущество — нативная поддержка Unix-команд, идеально подходящих для LLM благодаря их простоте, документированности и философии «делай одно дело хорошо». Это позволяет моделям эффективно передавать данные между инструментами, избегая сложностей.

Доступ к файловой системе решает главные проблемы браузерных аналогов вроде ChatGPT: отсутствие памяти между сессиями и ограниченный контекст. Claude Code накапливает знания, пишет заметки сам себе и сохраняет состояние, что открывает новые сценарии использования, даже если модели не станут умнее.

• Пользователи восхищаются способностью Claude Code и подобных инструментов взаимодействовать с системой через CLI, используя стандартные утилиты (adb/logcat, AWS CLI, tmux) для отладки, автоматизации и решения сложных задач в реальном времени.
• Подчёркивается преимущество Unix-философии и текстовых интерфейсов для интеграции с ИИ: простота, композируемость инструментов, использование stdout/stdin и файловой системы как универсального API, что делает их идеальными для агентов.
• Высказываются опасения по поводу конфиденциальности данных при использовании облачных ИИ-сервисов, а также желание полностью локальной работы с открытым ПО (Obsidian, локальные LLM).
• Отмечается, что ИИ эффективно использует существующие инструменты (линтеры, браузеры через кастомные скрипты, man-страницы) лучше, чем пытается решать задачи самостоятельно, что повышает качество результата.
• Наблюдается полярность мнений: одни видят в CLI-инструментах революцию и возрождение, другие считают их переоцененными или отмечают, что аналогичные возможности уже есть у других продуктов (Gemini CLI, Warp, Cursor, Copilot).

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

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

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

Zig предлагает более простой подход к созданию CLI-инструментов по сравнению с Rust, особенно когда речь идёт о работе с памятью. В Rust строгий borrow checker предотвращает ошибки на этапе компиляции, но часто вынуждает переписывать код под его требования, усложняя разработку. Например, при попытке добавить новую запись в список, одновременно удерживая ссылки на существующие, компилятор Rust блокирует действие из-за конфликта владения и заимствования.

В Zig же разработчик напрямую управляет памятью через аллокаторы, используя указатели и мутацию без сложных правил времён жизни. Это требует дисциплины, но даёт больше гибкости и скорости написания кода. Для CLI-инструментов, где производительность и простота часто важнее абсолютной безопасности памяти, Zig оказывается практичнее. Безопасность — это не только отсутствие ошибок памяти, но и читаемость, скорость разработки и соответствие задаче.

• Обсуждение затрагивает проблемы безопасности в C, связанные с ручным управлением памятью, и ироничные комментарии по этому поводу.
• Пользователи делятся мнениями о современных языках (Nim, Odin, V, D, Zig), отмечая их преимущества, такие как интероперабельность с C и гибкость в управлении памятью.
• Уточняется функциональность Zig: он не компилируется в C, но имеет инструмент для трансляции C-кода в Zig, при этом компилируясь напрямую в машинный код.
• В обсуждении присутствует юмористический тон относительно утверждения, что разработчики не являются идиотами.

Нетехнический основатель перестроил сайт стартапа с помощью ИИ-агента Claude Code за недели вместо месяцев изучения кода. Использовал стек: VS Code, CLI Claude, GitHub CLI и сервер Figma MCP для точного переноса дизайна из Figma в код на Remix. Качество ответов Claude варьировалось — иногда он менял не те части кода, что отнимало часы.

Рабочий процесс включал локальную разработку, пуши в ветку и создание пул-реквестов через Claude. Ключевой трюк: просить Claude выступать в роли CTO для ревью PR, что помогало находить упущенные оптимизации. Это позволило избежать шаблонных решений no-code платформ и точно реализовать кастомный дизайн.

• Рекомендуется активно управлять контекстом при работе с ИИ-ассистентами, очищая его между задачами для повышения фокуса и снижения смещения.
• Использование ИИ для генерации кода требует осторожности и постоянного контроля человека из-за риска ошибок, изменения не тех файлов и создания запутанного кода.
• Эффективные стратегии работы включают поэтапное планирование задач, сохранение промежуточных результатов и использование нескольких инструментов (Claude Code, Cursor, Figma MCP).
• Мнения разделились: одни видят в ИИ значительный прирост продуктивности, другие считают его использование избыточным или ведущим к потере времени.
• Ключевые проблемы: сложность поддержки сгенерированного кода, нарушение принципов проектирования и необходимость чётких промптов для качественного результата.

pass — менеджер паролей в духе Unix.
Каждый пароль — отдельный gpg-файл в ~/.password-store; можно каталогизировать, копировать, версионировать в git.

Команды:

• pass — список;
• pass site.com — показ;
• pass -c site.com — 45 с в буфере;
• pass insert site.com → ввод;
• pass generate site.com 15 → создать;
• pass rm site.com — удалить;
• pass git push/pull — синхронизация.

Установка: apt/yum/pacman/brew install pass или tar.

• pass — это минималистичный CLI-менеджер паролей на Bash + GPG; кто-то использует 10+ лет и доволен, кто-то уже ушёл.
• Главные претензии: неструктурированные файлы (приходится парсить в каждом скрипте), GPG-ключи сложны, плагинов/нормальных мобильных клиентов почти нет, Android-приложение заархивировано.
• Уязвимость: если агент GPG закешировал ключ, любой скрипт может выполнить pass и выкачать все секреты; спасает только PIN + touch на YubiKey.
• Удобные альтернативы: KeePassXC/KeePassDX, Bitwarden (есть CLI), Vaultwarden; синхронизация pass через Git работает, но историю зашифрованных файлов не посмотреть обычным git diff.
• Для shared/корпоративного использования нет аудита доступа и нормального способа перешифровки для новых сотрудников — приходится менять все пароли.

Коротко: в NPM проникли популярные пакеты (colors, debug и др.) через фишинг письмо «смени 2FA». Вредоносный код подменял адреса криптокошельков.
Почему это мелко: библиотеки используются в CLI-утилитах, а не в Web3; украденные API-ключи или майнеры были бы катастрофой.
Вывод: любая зависимость может быть трояном, но проверять всё дерево пакетов никто не успевает — надо успевать релизить.

• Атака на NX через NPM показала, что даже популярные плагины могут стать вектором для кражи creds и API-кейсов.
• Участники сходятся: «всё дерево зависимостей NPM по умолчанию доверяет всем», а ручная проверка каждой мелкой библиотеки невозможна при скорости релизов.
• Многие выжили лишь благодаря «отложенным обновлениям», изоляции в контейнерах или отказу от экосистемы Node/NPM целиком.
• Фишинг на домене npm.help подтвердил, что даже IT-специалисты не всегда замечают поддельные TLD; предлагают белые списки ссылок и DMARC-индикаторы в клиентах.
• Утверждение «мы просто не заметили более продвинутые атаки» звучит всё чаще: Jia Tan 3.0, по мнению комментаторов, уже где-то в supply-chain.

Команда Alex переходит в OpenAI

Мы присоединяемся к команде Codex в OpenAI.
Начав с «безумной» идеи создать «Cursor для Xcode», мы построили лучшего AI-агента для iOS и macOS. Теперь продолжим эту миссию в OpenAI.

Что будет с Alex

• Приложение останется работать у текущих пользователей.
• С 1 октября скачивание прекращается.
• Новых функций не будет.

Спасибо бета-тестерам, клиентам, инвесторам и всему Apple-сообществу! ❤️

P.S. Попробуйте Codex CLI.

• Команда Alex Code присоединилась к OpenAI: продукт перестанет развиваться, новые загрузки прекратятся 1 октября.
• Пользователи считают, что Apple «зашерлокила» большую часть функций Alex во встроенном AI Xcode, поэтому выживание стартапа стало невозможным.
• Многие видят в сделке типичный aqui-hire: OpenAI получает инженеров, знакомых с IDE и Apple-платформами, а не уникальную технологию.
• Вопрос будущего: станут ли OpenAI/Anthropic прямыми конкурентами IDE-стартапов вроде Cursor или останутся поставщиками моделей.
• Скептики ждут, что через 12–18 месяцев продукт Alex окончательно закроют, а команду полностью интегрируют в Codex.

Monodraw — редактор ASCII-графики для macOS (11 Big Sur+).
Пробная версия бесплатно, лицензия — $9.99, скидки для учебных заведений.

Возможности

• Диаграммы: структуры данных, алгоритмы, ER-диаграммы (нотация «Crow’s Foot»).
• Mind-map: свободное размещение текста на бесконечном холсте.
• Баннеры: 148 встроенных шрифтов FIGlet, изменение размера и выравнивание.
• Инструменты: прямоугольники, линии (ортогональные, лестницы), текст, карандаш, ластик, заливка, пипетка.
• Точки крепления: линии автоматически цепляются к фигурам.
• CLI: генерация документации в хуках Git, экспорт JSON.
• Группы, направляющие, фокус-режим, горячие клавиши для быстрой работы.

Экспорт: PNG, SVG.

• Разработчик Monodraw отвечает на вопросы; пользователи делятся альтернативами (asciiflow, textik, durdraw, REXPaint).
• Все хвалят чистоту результата, низкую цену ($10 навсегда) и удобство вставки ASCII-диаграмм прямо в код или документацию.
• Основные сценарии: комментарии в исходниках, схемы сетей, баннеры серверов, ASCII-анимации, план кухни.
• Главный недостаток: приложение только для macOS; много просьб портировать на Linux.
• Новая текстовая разметка (апрель 2025) улучшает работу с системами контроля версий.

CLI-утилитам не место в ~/Library/Application Support

Популярные библиотеки (Python platformdirs, JS env-paths, Rust dirs, Go adrg/xdg) по умолчанию кладут конфиги в ~/Library/Application Support, но это каталог для GUI-приложений. Пользователи ожидают увидеть настройки CLI-программ в ~/.config, как Git, Vim, Tmux и сотни других. Это ожидание закреплено стандартом XDG и принципом «наименьшего удивления».

Почему это важно

• Неожиданное расположение ломает привычки и усложняет версионирование.
• Даже менеджеры dotfiles (chezmoi, dotbot, yadm, rcm, GNU Stow) игнорируют ~/Library/Application Support, что подтверждает: сообщество считает ~/.config единственным разумным местом для конфигов CLI-утилит на macOS.

• Автор утверждает, что CLI-утилиты macOS должны хранить конфиги в ~/.config по XDG, но участники показывают: ни одна поставляемая с macOS утилита этого не делает.
• Большинство считает XDG спецификацией для Linux/Unix-сред и не видят оснований навязывать её macOS, у которой есть собственные места: ~/Library/Preferences и ~/Library/Application Support.
• Разработчики CLI-инструментов, портированных с Linux, действительно часто используют ~/.config, что вызывает у местных пользователей ощущение «плохого порта».
• Предлагаются компромиссы: использовать XDG-переменные, если они заданы, или делать симлинки между ~/.config и ~/Library/Application Support.
• В Rust-экосистеме крейт dirs-rs игнорирует XDG на macOS; участники обсуждают создание форка, который бы следовал спецификации.

RepoMirror — сервис для зеркалирования репозиториев GitHub.

• Как работает: клонирует репозитории и обновляет их по расписанию.
• Форматы: поддерживает Git, LFS, релизы, issues, PR, wiki.
• Доступ: публичные и приватные репы (OAuth-токен).
• Скорость: CDN, параллельные загрузки, дедупликация.
• API: REST/Webhook для управления зеркалами.
• Статистика: размер, частота обновлений, ошибки.
• Архив: хранение старых снапшотов.
• CLI: repomirror sync <owner>/<repo>.
• Самостоятельный хостинг: Docker-образ + конфиг repomirror.yml.

• Появится новая «грязная» работа: разгребать legacy-код, порождённый «vibe-coding’ом» продажниками.
• Агенты в цикле успешно портировали код, но иногда убивали себя pkill’ом, чтобы выйти из бесконечного цикла.
• Короткие промпты (≈100 слов) работают лучше 1500-словных «улучшений» — агенты быстрее и умнее.
• Без чётких тестов и стиля код «почти работает», но превращается в неподдерживаемый slop.
• Стоимость: Sonnet-агент ≈ $10,5/час; без лимитов легко проснуться с огромным счётом.

TL;DR
Claude Code (CC) радует, потому что максимально прост: один цикл, один контекст, минимум абстракций. Повторить магию можно, если:

1. Один цикл – без мульти-агентов, максимум один «дочерний» процесс.
2. Маленькая модель – для всего, кроме основной задачи.
3. claude.md – живой файл, где агент и пользователь договариваются о стиле и контексте.
4. Теги и примеры – XML, Markdown, куча примеров в промптах.
5. Инструменты
   • Поиск через сам LLM, а не RAG.
   • Высокоуровневые «умные» инструменты (edit, read, todo) вместо низкоуровневых команд.
   • Агент сам ведёт todo-список и отмечает выполненное.
6. Управление стилем – явные просьбы «ЭТО ВАЖНО» и алгоритмы с эвристиками прямо в промпте.

---

1. Цикл

• Одна история сообщений – легко дебажить.
• Подпроцессы – CC может вызвать себя же, но глубина = 1.
• Маленькая модель – подсчёт токенов, сводка diff, украшения UI – всё ей.

---

2. Промпты

• claude.md лежит в корне репо; агент читает и пишет туда же, чтобы «запоминать» договорённости.
• XML-теги (<thinking>, <result>) + Markdown + примеры кода – структурируют вывод и уменьшают бред.

---

3. Инструменты

• LLM-поиск – просим модель выдать до 20 релевантных файлов; быстрее и точнее эмбеддингов.
• Высокий уровень
  • str_replace_editor – редактирует блоки кода, а не строки.
  • todo – агент сам пишет / вычёркивает задачи; видно прогресс.
• Никаких низкоуровневых sed, grep и прочего UNIX-морока.

---

4. Управление

• Тон – «вежливый, лаконичный, не болтает лишнего».
• Капс и «ВАЖНО» – прямо в промпте, работает.
• Алгоритм – пишем в промпте: «если X → сделай Y, иначе спроси», + примеры.

---

Заключение

CC выигрывает за счёт самоограничений: один файл кода, один цикл, простые инструменты. Не усложняйте – дайте модели хороший каркас и позвольте «готовить».

• Критика: пост назван «Что делает Claude Code таким хорошим», но не сравнивает его с другими инструментами, а просто пересказывает документацию.
• Пользователи делятся опытом: кто-то на CC уже построил MVP с платящими клиентами, кто-то сталкивается с регрессиями и «ленью» агента.
• Безопасность: многие боятся давать CLI-инструменту полный доступ к системе, ключам и репозиториям.
• Альтернативы: советуют OpenHands CLI, aider и другие open-source решения; обсуждают, как подключить собственные LLM.
• Тезис «Claude хорош, потому что модель умеет разбивать задачи на шаги и работает в unix-окружении» повторяется как ключевой.

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.