OpenCode 2.0 — крупное обновление агентной среды разработки, основанное на опыте миллионов ежедневных пользователей. Ключевое изменение — сервер теперь автоматически работает как единый фоновый процесс на машине: интерфейс TUI, веб-версия и десктопное приложение обращаются к одному центральному процессу. Программный клиент @opencode/client автоматически находит локальный сервис, что удобно для запланированных задач; сервер можно открыть другим хостам через команды /pair или opencode pair.

API переписан с нуля: старый рос хаотично и был плох, новый поддерживает почти любые сценарии. OpenCode осведомлён о собственном API и вызывает его — например, переносит текущую сессию в git worktree при начале новой работы. Выпущен новый пакет @opencode/client с клиентами для обычного JavaScript и Effect.

Режим Code Mode использует минимальный интерпретатор JavaScript из @opencode/codemode: он превращает MCP-серверы и OpenAPI-эндпоинты в функции, которые агент вызывает в скрипте — один круговой обход вместо множества вызовов, а все MCP-серверы по умолчанию работают через codemode без раздувания контекста. Добавлены фоновые субагенты (в том числе с другой моделью) и асинхронные shell-команды. Почти все функции 2.0 реализованы как внутренние плагины (их более 80), TUI-плагины стабильны, всё поддерживает горячую перезагрузку — агент может написать плагин для себя прямо в сессии. Пакет @opencode/sdk позволяет использовать OpenCode как библиотеку. При обновлении учтите несовместимости: плагины 1.0 не работают, серверный API полностью изменён, tui.json переименован в json.

OpenCode 2.0 привёл к значительным улучшениям в клиент‐/серверной архитектуре и плагинах: плагины и навыки автоматически перезагружаются, конфигурацию можно редактировать через встроенный навык, а переход на клиент‐/серверную модель повысил удобство использования. Автоматический GitHub‐апп для трекинга багов запускает тесты, получает реплики и записывает видео TUI‐ошибок, ускоряя отладку до двух минут. Опция opentunnel позволяет пробрасывать любые сервисы через уникальный поддомен *.opentunnel.xyz, упрощая удалённый доступ без дополнительной настройки. Однако версия выявила проблемы: высокое потребление памяти (до 2 ГБ), недостаточную безопасность постоянного демона, ограниченную поддержку прокси (отсутствие SOCK5 в HTTPS_PROXY), медленную работу веб‐интерфейса и сложности с буфером обмена в Ubuntu/X11. Некоторые пользователи считают постоянный демон нежелательным по умолчанию, другие — необходимым для согласованной работы клиент‐сервера. Практические советы: для ускорения установки перенаправлять вывод скрипта через cat (чтобы избежать медленного рендеринга прогресс‐бара); при переходе на 2.0 добавить отдельный sandbox (bubblewrap, firejail) вокруг клиента, так как прежний песочничный слой может стать неэффективным из‐за вызова всех инструментов через фоновой процесс; для Ubuntu/X11 проверять настройки X11‐clipboard или использовать альтернативный менеджер буфера обмена; мобильным пользователям рекомендуется использовать десктопный клиент или упрощённый UI из‐за тяжелой читаемости сайта на телефонах; для снижения нагрузки на диск регулярно очищать временные файлы (в прошлом OpenCode заполнял 2 ТБ хранилища). OpenCode 2.0 сохраняет бесплатный tier без логина, упрощая быстрый старт и привлекая новых пользователей. Пользователи ценят возможность запускать нативные приложения, подключающиеся к серверу OpenCode, что упрощает работу на удалённых хостах и делает модель более гибкой.

В Anthropic узким местом разработки стала не генерация кода, а инфраструктура для людей: система контроля версий, сборки и CI. Если в мае 2026 года в монорепозиторий вливалось в среднем около 2 500 изменений в день, то к сентябрю — уже более 30 000. Рост не замедляется: спрос на слияние кода практически бесконечен, и снятие каждого узкого места сразу увеличивает объём производимого кода.

Git плохо подходит для такой нагрузки. История главной ветки — почти 100 ГБ, а сжатая рабочая копия — свыше 25 ГБ; выполняется порядка 25 млн извлечений кода в день только для CI, что при наивной загрузке дало бы более 600 ПБ трафика. Обходные пути — shallow-клоны, sparse-checkout, promisor-remote, а также внутренние зеркала и «снимки» репозитория в хранилище — на пике это были сотни зеркал. Они выигрывали время, но становились всё сложнее в эксплуатации по мере роста частоты слияний: снимки отстают от вершины main, а операции вроде diff и blame на частичных клонах требуют всё больше усилий.

Решение — собственный контроль версий Scion, на который монорепозиторий полностью перевели с git за пять месяцев. В этот же срок создали поверхность код-ревью Antique, поиск по коду, систему управления доступом IAM и новые способы проводить большие объёмы проверенного кода. Ирония в том, что способность Claude писать код и создала проблему, и помогла быстро построить масштабируемую систему. Anthropic планирует делиться наработками с сообществом git, GitHub и GitLab.

Обсуждение дополняет статью скепсисом относительно качества кода при темпе 30к мержей в день и ставит под сомнение техническую необходимость отказа от Git в пользу кастомного решения, сравнимого с возвратом к SVN. Часть пользователей считает отказ от Git неизбежным при агентном кодинге (@jqdsouza, @Gepsens), другие (@bob1029) не видят технических доказательств, что Git не справился бы с такой нагрузкой при правильной настройке. Пользователи спорят о качестве кода: @duttish находит в коде Claude «кривые вещи» (janky crap), что вызывает вопросы о том, как Anthropic обеспечивает ревью 30 000 PR в день без потери качества. Роль инженера смещается от написания кода к функции «контролера», чья основная задача — говорить нейросети «нет», когда она нарушает системные ограничения ради следования паттернам (@alex_suzuki, @kburman, @bob1029). Снижение стоимости написания кода с помощью ИИ делает экономически выгодным создание собственных кастомных инструментов вместо адаптации существующих решений (@kburman). Огромный объем изменений (churn rate) может быть признаком не эффективности, а отсутствия единого видения продукта или плохой архитектуры (@he0001, @netburst). Архитектурно Scion напоминает возвращение к централизованным системам контроля версий вроде Subversion (SVN) (@tatersolid, @mijoharas, @mey). Для коллаборации агентов в качестве альтернативы Git рекомендуется обратить внимание на Pijul (@blurbleblurble). Существует риск «FOMO-эффекта», когда другие компании начнут копировать подход Anthropic, не обладая их ресурсами и объемом данных (@preommr).

Между 15:06 и 15:16 UTC произошёл массовый сбой в работе ключевых сервисов GitHub: Git Operations, Pull Requests, Webhooks, Issues и Actions. Все системы одновременно испытали деградацию производительности или доступности, что нарушило работу миллионов разработчиков. Критически важные операции — коммиты, пул-реквесты, вебхуки и действия CI/CD — временно перестали отвечать, вызвав сбои в пайплайнах и потоках разработки.

К 15:24 UTC началось восстановление, и к 15:58 UTC все сервисы вернулись к стабильной работе. Причина инцидента не раскрыта, но устранение последствий заняло около 50 минут. Отдельно отмечено, что Actions временно оставался стабильным до 15:32, а Git Operations показал первые признаки восстановления уже в 15:27. Команда GitHub продолжила анализ корневой причины, обещая опубликовать детальный отчёт.

Статус‐страница GitHub часто отстаёт от реального состояния сервисов. Во время сбоя, длившегося около 40 минут, были недоступны push, pull‐request, Actions и вебхуки, что нарушило CI/CD пайплайны. Пользователи получали Internal Server Error, хотя страница статуса утверждала, что все системы работают. Иногда страница показывала, что PR работают, но коммиты в них исчезали, а страница поддержки тоже выдавала ошибку. SSO‐аутентификация также была недоступна без уведомления на статусе. Самостоятельно развернутые сервисы (Forgejo, Gitea, GitLab CE) продолжали работать без перебоев. Некоторые связывают сбой с добавлением GitHub новых диапазонов IP‐адресов для вебхуков в день инцидента. За последние два месяца наблюдались подобные сбои, подрывающие доверие к надёжности платформы. Мнения разделились: одни считают 40‐минутную длительность приемлемой, другие — недопустимой и используют как аргумент для миграции. Рекомендуется иметь резервные решения: самохостинг Git, альтернативные CI, локальные копии репозиториев и не полагаться полностью на статус‐страницу.

Следующее поколение разработки — это агенты, которые пишут код, исправляют баги и обновляют зависимости в масштабе сотен и тысяч одновременно. GitHub был создан для людей, но для агентов нужна новая основа: управление конфликтами, отслеживание мотивации изменений и координация параллельной работы. Cloudflare запустил Artifacts — масштабируемую систему версионного хранения, совместимую с Git, где каждый агент может иметь собственный репозиторий, а изменения автоматически деплоятся через Workers.

Artifacts позволяет создавать репозитории программно, хранить контекст агентов и автоматически деплоить код в Workers — как в продакшн, так и в изолированные превью для тестирования. Теперь участники конкурса могут построить на этой основе новую платформу для агентной разработки: переосмыслить ветки, код-ревью, слияния или придумать новые способы сравнения и выбора изменений. Победители получат $25 000 кредитов Cloudflare, приглашение на Cloudflare Connect и полёт в Сан-Франциско. Конкурс открыт до 14 октября 2026 года, участие требует видео, открытого кода и инструкций.

Участники сомневаются в целесообразности создания новой Git‐платформы на Cloudflare из‐за рисков централизации: это потенциальная точка отказа технически и политически, вызывает недоверие из‐за возможных MITM‐атак и вмешательства правительств, неприемлемо для критически важных систем. Предлагают проверенные децентрализованные альтернативы: GitSocial, Walgit, хранение в S3‐совместимых бакетах (например, R2), либо bare‐репозитории по SSH без веб‐интерфейса для офлайн‐работы. Некоторые считают Git неподходящим для масштабных агентных сценариев и предлагают Fossil или SVN, другие полагают, что менять Git не нужно. Бюджет в $25 000 и срок в три месяца признаны нереалистичными для создания продукта, способного принести миллионы; советуют вместо этого построить собственный стартап на LLM. Идея «Git для ботов» воспринимается как странная и малопривлекательная, конкурс считают глупым, сомневаются в практической ценности платформы.

Переход Git 3.0 на SHA-256 в качестве алгоритма хеширования по умолчанию — это дорогостоящая ошибка, которая принесёт больше проблем, чем пользы. SHA-1, несмотря на теоретическую уязвимость к коллизиям, на практике никогда не приводил к реальным сбоям в репозиториях Git за два десятилетия использования. Вероятность случайной коллизии настолько мала (порядка 1,4 септиллиона файлов в одном проекте), что её можно пренебречь. Реальные атаки типа SHAttered требуют целенаправленных усилий и не угрожают обычным рабочим процессам.

Основной аргумент против перехода — колоссальная стоимость миграции: все существующие репозитории, инструменты, скрипты и интеграции, построенные вокруг SHA-1, потребуют обновления или полной переработки. Это вызовет глобальные сбои в CI/CD, инструментах анализа кода, системах резервного копирования и сторонних сервисах. Вместо радикальной смены алгоритма автор предлагает более разумное решение: добавить вторичную подпись на основе SHA-256 к существующим объектам Git, сохраняя SHA-1 как адресный ключ. Такой подход обеспечит криптографическую целостность без разрушения экосистемы, удовлетворит требования NIST и уберёт излишние нагрузки от механизмов обнаружения коллизий (sha1dc). В итоге, выгода от перехода на SHA-256 минимальна, а издержки — огромны и распространятся на весь мир разработки.

Переход на SHA-256 в Git 3.0 технически реализуем с обратной совместимостью, но сталкивается с практическими проблемами совместимости подмодулей и инфраструктуры, а не с криптографической необоснованностью. SHA-1 не является теоретической уязвимостью — атака SHAttered 2017 года доказала практическую возможность коллизий. Git не был затронут, потому что никто не пытался подобрать префикс git-blob. Коллизии позволяют внедрять вредоносный код, если два репозитория имеют одинаковый хеш коммита, но разное содержимое в рабочей директории. Fossil SCM перешёл на SHA3-256 за 6 дней после SHAttered, сохранив старые хеши и не требуя перестройки репозиториев — миграция возможна без поломки ссылок. Git-документация подтверждает наличие двунаправленного отображения между SHA-1 и SHA-256, позволяющего ссылаться на объекты по старым хешам, но ограничивает смешанные репозитории и подмодули. Linus Torvalds в 2007 году заявлял, что SHA-1 в Git — это не функция безопасности, а средство проверки целостности, что ставит под сомнение необходимость перехода ради «безопасности». GitHub пока не поддерживает SHA-256 репозитории; автор статьи, возможно, фальсифицировал скриншот интерфейса. Выбор формата по первому коммиту — разумное решение. Подмодули в SHA-256 репозиториях могут ссылаться на SHA-1 подмодули — тесты на Git 2.47.3 подтверждают, что это работает без ошибок. Предлагается использовать git2/git3 как алиасы для выбора хеш-алгоритма при инициализации репозитория, чтобы избежать случайного перехода на SHA-256 в старых средах. Компании и госорганизации, запрещающие SHA-1 по политике безопасности, вынуждают Git перейти на SHA-256 не из-за криптографических угроз, а из-за требований сертификации. Утверждение, что SHA-256 — это «новый IPv6», опровергается: переход не требует полной замены инфраструктуры, а использует маппинг хешей, что делает его менее разрушительным. Хеш-коллизии в Git не являются проблемой для большинства пользователей, так как они используют сокращённые хеши (7–10 символов), а не полные, и не полагаются на них как на криптографические доказательства. Атака «Shambles» — это chosen-prefix collision, ближе к second-preimage, чем к обычной коллизии, и поэтому представляет более серьёзную угрозу, чем утверждает автор статьи. Предлагается хранить оба хеша (SHA-1 и SHA-256) в репозитории после миграции, чтобы старые ссылки не ломались, как это делает Fossil SCM. Математическая вероятность случайной коллизии SHA-1 в одном проекте — 1.4 септиллиона файлов, но это не учитывает целенаправленные атаки, которые требуют лишь тысяч вычислений. Переход на SHA-256 — это не только вопрос безопасности, но и инфраструктурной устойчивости: Git должен быть готов к будущим сменам хеш-функций, а текущий подход не обеспечивает криптографической гибкости.

Parley — это федеративный чат, построенный поверх IRC, где каждый домен запускает собственный инстанс, а пользователи идентифицируются как email: alice@foo.com, bob@bar.com. Инстансы автоматически обнаруживают друг друга через DNS и обмениваются подписанными сообщениями по HTTPS, позволяя обычным IRC-клиентам (irssi, WeeChat, Textal и др.) общаться без плагинов. Сообщения типа /msg alice@foo.com hi работают сразу, даже если инстансы ранее не взаимодействовали — федерация устанавливается на лету.

Система поддерживает стандартные IRCv3-расширения: server-time, message-tags, echo-message, multi-prefix, setname и relaying клиентских тегов (например, индикаторы набора текста) через федерацию. История сообщений по умолчанию хранит последние 50 строк (было 20). Глобальные каналы вроде #lobby реплицируются между инстансами, отображая только количество участников и список доменов, без раскрытия имён пользователей — это делается через подписанные hello-снимки. Из известных ограничений: нет per-user ключей и end-to-end шифрования, нет канальных модов и операторов (глобальные каналы ничьи), ники привязаны к аккаунтам, а веб-интерфейс служит только для администрирования — чат остаётся делом IRC-клиентов. Проект лицензирован под MIT, тесты покрывают end-to-end сценарии через make test.

Обсуждение выявило серьёзные практические проблемы федеративного чата Parley: отсутствие централизованных операторов делает модерацию почти невозможной, спам и DDoS‐атаки считаются неизбежными, а сама идея воспринимается как переизобретение уже существующих протоколов (Matrix, XMPP) вместо использования готовых федеративных сетей. Одни считают, что отсутствие операторов каналов делает блокировку пользователей непрактичной, требуя от каждого админа блокировать злоумышленников на своём сервере; другие предлагают использовать репутационные списки блокировок, которые могут быстро распространяться между администраторами, как в системе спам‐фильтров email. Для решения проблемы модерации предлагается внедрить репутационные фильтры, позволяющие администраторам подписываться на блок‐листы друг друга, аналогично общим спам‐листам в почтовой системе. Множество участников согласились, что спам и возможность масштабных DDoS‐атак через динамически создаваемые серверы являются главным риском для любой децентрализованной IRC‐сети. Parley по сути повторяет функции уже существующих федеративных протоколов, таких как Matrix и XMPP, и поэтому не предлагает принципиально новых возможностей. Некоторые советуют построить приложение поверх уже существующей федеративной сети (например, ActivityPub или atproto), чтобы избежать создания отдельной учетной базы и упростить интеграцию. Несколько участников подчеркнули, что IRC уже имеет элементы федерации через связку серверов, но глобальные каналы без операторов создают новые сложности в управлении. Для упрощения деплоя предлагается использовать чистый Go‐SQLite вместо C‐биндингов, что облегчает создание минимальных Docker‐образов без необходимости наличия C‐runtime. Было отмечено, что удобство Parley может способствовать росту бот‐свармов, о чём уже предупреждались в контексте других децентрализованных систем.

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.

FoxDev Studio — это среда разработки, позволяющая запускать и редактировать приложения Visual FoxPro 9 без необходимости переписывать, конвертировать или экспортировать код. Она открывает существующие проекты, формы, таблицы, классовые библиотеки, меню и отчёты напрямую из файлов на диске, сохраняя их структуру и содержимое неизменными. IDE включает привычные инструменты: редактор кода с линтером, отладчик с пошаговым выполнением и просмотром локальных переменных, обозреватель проектов и таблиц, а также командное окно — всё расположено так, как в оригинальном Visual FoxPro. Данные читаются и записываются на месте, без преобразования, поэтому после работы файлы остаются теми же, что и были.

Среда поддерживает взаимодействие с системными вызовами, COM-объектами и старыми библиотеками, на которых зависит приложение, обеспечивая полную обратную совместимость. Помимо классической разработки, FoxDev Studio включает FoxScript — расширение языка с поддержкой лямбда-функций, новых типов данных и HTTP API, позволяющее создавать веб-серверы прямо из FoxPro-кода, как показано на скриншоте с прослушиванием порта 8080. Доступны сборки для Windows, Linux (AppImage и .deb) и исходный код на GitHub. Документация охватывает виртуальную машину, байт-код, инструкции, новые языковые возможности и HTTP API. В планах — завершение поддержки языка, реализация конструктора и движка отчётов, работа с большими таблицами (>2 ГБ) через 64-битные смещения и создание установщика для готовых приложений.

Visual FoxPro всё ещё используется в крупных нишевых бизнесах, включая компании с оборотом более $400 млн, даже в 2026 году. Однако сопровождается проблемами безопасности и масштабируемости: отсутствие схемы прав доступа в DBC позволяет выполнять произвольный код через хранимые процедуры, а работа по сети приводит к блокировкам файлов и конфликтам записей. Многие советуют мигрировать на SQL‐базы или переписывать приложения на .NET для устранения этих проблем. Низкий порог входа и быстрая разработка сделали VFP популярным в 90‐х и начале 2000‐х — например, за месяц создали CRUD‐приложение для канадского рынка оценки недвижимости и продали 300 лицензий по $299. Ностальгия по удобному дизайнеру форм и встроенному браузеру баз сохраняется, однако современные разработчики переходят на .NET или другие платформы. Некоторые компании поддерживают сотни тысяч строк кода на VFP (например, 500 KLOC, обслуживая бизнес стоимостью $500 млн) и ищут пути постепенной миграции — с помощью инструментов конвертации в PostgreSQL или AI‐поддержки. Считается, что переписать приложение проще, чем воссоздавать старый runtime, чтобы избежать двойных проблем совместимости и поддержки. При росте системы на VFP её возможности быстро исчерпываются, особенно при работе с DBF-файлами по сетевым дискам.

AX — это декларативная платформа для запуска агентных задач в масштабе, построенная на Agent Substrate. Она изолирует задачи в sandbox-окружениях, управляет их жизненным циклом и позволяет запускать миллиарды одновременных агентов на одном кластере благодаря лёгким актёрам и плотному мультиплексированию ресурсов. Каждая задача описывается в YAML-файле (например, task.yaml), где указываются workspace (с Git-репозиториями или генеративным описанием окружения) и цель задачи. После применения конфигурации через ax apply система создаёт workspace и задачу, после чего можно отслеживать её статус, подключаться по SSH, выполнять команды, приостанавливать и возобновлять выполнение — всё с субсекундным временем восстановления из спящего режима.

AX специально разработан для агентных workloads, которые отличаются от микросервисов и batch-задач: они сохраняют состояние, делают вызовы к моделям и внешним инструментам, могут простаивать ожидая ответа и тратят ресурсы, если не управляются. Платформа решает эту проблему через четыре примитива: задачи, workspace, сетевые политики и модели, обеспечивая декларативное управление. Благодаря генеративным возможностям, окружение можно настроить просто описав его на английском (например, «Set up a Python 3 development environment»), после чего AX сам подготовит его. Это делает AX идеальным для исследователей и разработчиков: от интерактивного программирования и Jupyter-ноутбуков до масштабного обучения с подкреплением и оценки агентов в воспроизводимых песочницах. AX минимален, эргономичен и ориентирован на joyful workflow — чтобы фокус оставался на исследовании, а не на инфраструктуре.

Обсуждение ставит под сомнение простоту AX: требуется полный кластер Kubernetes, контейнерный реестр и доступ к Agent Substrate API, что делает его менее доступным. AX дублирует возможности Kubernetes, создавая избыточный слой и заставляя писать сложные YAML без уникального функционала. Демонстрация показывает лишь паузу и возобновление задачи, не раскрывая реальных сценариев применения. Главная сложность в оркестрации агентов — определение их состояния и автоматическое реагирование, требующее надёжного мониторинга. У опытных пользователей уже есть аналогичные решения (Mastra, Clrk), предоставляющие контроль над сетью и изоляцию, снижающие необходимость в AX. Некоторые предпочитают аппаратную сегрегацию (мини‐ПК) для изоляции агентов. Название «Google’s AX» вводит в заблуждение — нет официальной поддержки Google или DeepMind. Пользователи недовольны объёмными YAML‐конфигами и предлагают более простые способы описания задач. Инструменты вроде Scion, LangGraph или kagent предлагают более зрелый и интегрируемый подход. Agent Substrate уже покрывает изоляцию, ресурсное планирование и сетевой контроль, делая эти функции базовыми для платформ агентов. Отсутствуют публичные бенчмарки и сравнения производительности, требуются эмпирические данные. Экосистема фрагментирована: каждый разрабатывает собственный фреймворк, что приводит к повторному изобретению решений.

ZCode, официальное приложение для кодирования от Zhipu, тайно собирает и загружает в облако полную историю вашего рабочего пространства, включая весь .git-каталог, LFS-кеш, reflogs и глобальные настройки приложения. Данные упаковываются, шифруются публичным ключом, полученным с сервера, и отправляются в Aliyun OSS, при этом приватный ключ остаётся исключительно на стороне сервера — расшифровать загруженный архив локально невозможно даже для самого клиента. Этот процесс происходит без ведома пользователя, запускаясь при каждом входе в систему и перед каждым запросом к ИИ через механизмы captureBeforePrompt и repo-wiki-update, несмотря на заявления компании о привязке загрузки только к генерации Wiki-страниц.

Позже Z.ai подтвердила факт загрузок, объяснив их необходимостью для индексации кодовой базы и восстановления сессий, но утверждает, что данные уничтожаются сразу после создания Wiki в облаке и не хранятся. Однако расследование показало, что в ранних версиях (3.12.3) отключение опций вроде «Optimize Experience» не останавливало загрузку, а в обновлённой версии 3.14.0 соответствующий код был физически удалён. Как временную меру защиты пользователи могут заблокировать директорию ~/.zcode/v2/checkpoints на уровне ОС — через chflags nouchg в macOS или sudo chattr +i в Linux — что предотвращает запись и, следовательно, загрузку данных, хотя и отключает функцию отката изменений. Это подчёркивает конфликт между удобством ИИ-инструментов и правом пользователя на контроль над своими данными.

ZCode тайно загружает полную историю Git, включая .git и reflogs, без уведомлений и согласия. Подобные практики распространены среди закрытых AI-харнессов, особенно китайских провайдеров (GLM, DeepSeek), вызывая массовое недоверие к проприетарным инструментам. Шифрование данных публичным ключом с хранением приватного ключа только на сервере делает локальные резервные копии удалёнными активами — эквивалентно извлечению данных без согласия. Отсутствие упоминания сбора данных в политике конфиденциальности, FAQ и changelogах делает действия ZCode потенциально уголовно наказуемыми. Пользователи считают, что бесплатные или сверхдешёвые токены — компенсация за сбор данных для обучения моделей, а не подарок. Попытки чтения dotfiles и файлов из .gitignore подтверждают системную тенденцию агентов проникать в любые доступные данные без согласия. Отсутствие логов загрузки не означает отсутствия сбора — это часть дизайна. Открытые решения (OpenCode, Pi.dev, swival.dev) предпочтительнее: код доступен для аудита, данные не отправляются в облако без явного согласия, мотивация провайдера не направлена на эксплуатацию. Использование FUSE для изолированных файловых систем с фильтрацией секретов — реакция на полное отсутствие доверия к AI-инструментам. Споры о том, что локальный запуск подразумевает согласие, опровергаются: это эксплуатация доверия, а не согласие. Подобные инциденты — повторяющийся паттерн, а не единичный сбой, что подрывает доверие ко всем проприетарным AI-инструментам.

Маленькие знания часто дают большой эффект в повседневной работе инженера. Например, ctrl + r в терминале можно улучшить с помощью fzf для нечёткого поиска истории или atuin, который хранит историю в SQLite и позволяет искать по директориям. В SQL можно выполнять SELECT без FROM — удобно для тестирования функций или проверки выражений вроде SELECT TRUE <> NULL. Для оптимизации запросов в PostgreSQL и MySQL полезно EXPLAIN ANALYZE, которое выполняет запрос и показывает детальную производительность. В регулярных выражениях \b помогает находить границы слов, а логарифмы удобны для bucketing метрик — например, Math.floor(Math.log10(count)) группирует значения по порядкам величины. В современном JavaScript полезны Array.flatMap, Object.entries и Promise.withResolvers, а в Node.js — повторное использование HTTPS-соединений через https.Agent, что снижает латентность. В Git: git log -S pattern ищет коммиты, где строка была добавлена или удалена («git pickaxe»), git checkout - переключается на предыдущий HEAD, а вместо find часто достаточно **/*.md при включённом globstar в Bash. Для поиска по содержимому файлов лучше использовать rg (ripgrep), а в Zsh стоит включить автодополнение через compinit и настроить FPATH для функций от Homebrew. Эти приёмы не требуют глубоких знаний, но экономят время и снижают когнитивную нагрузку. Аналогично в компаниях ценны небольшие внутренние лайфхаки: какой источник данных смотреть при проблеме, кто эксперт в определённой области, где лежит документация по сложной теме, когда нужно вручную масштабировать систему, какая команда делает rolling restart, какой утилитой удобно скриптировать рутинную задачу. Один такой совет в день — достаточно, чтобы не перегружать команду, но полезно для тех, кто ещё не знал этого трюка. Даже если вы знаете 9 из 10, десятый может сэкономить час работы и спровоцировать полезное обсуждение. Старшим инженерам стоит делиться такими знаниями — они формируют культуру эффективной работы.

Эффективность мелких трюков зависит от привычки и системного закрепления, а не от их наличия. Инженеры годами используют неоптимальные методы из-за привычки и лени, несмотря на знание более быстрых альтернатив. Записывайте полезные трюки в легко доступный документ — это помогает вспомнить их при необходимости, не полагаясь на память или поиск в интернете. Размещайте чит-листы на стене или в рабочем пространстве — физическое присутствие подсказок повышает вероятность их применения. Создавайте bash-алиасы или скрипты, которые 'порицают' за использование устаревших команд — это формирует новую привычку (как @lelandbatey с git switch). Храните редко используемые, но важные команды в файле типа ~/scratch.txt с grep-доступом — это надежнее, чем история shell. Используйте zoxide вместо cd — он запоминает частые директории и позволяет прыгать между ними без цепочек ../.. (как @disinterred). Используйте zhist для улучшенного поиска истории Zsh с контекстом — он лучше стандартного fzf (как @overflowy). Сохраняйте полезные команды в Makefile или инструментарии приложения — это делает их воспроизводимыми и устраняет необходимость вводить их вручную (как @cachvico). Пишите полезные трюки на собственном сайте — это делает их долговечными и удобными для обмена (как @AJRF). Изучайте трюки, наблюдая за тем, как AI выполняет задачи — часто AI использует неизвестные вам команды (например, в perf, как @kccqzy и @SebasDev). Спор: Некоторые считают, что трюки вроде SELECT без FROM зависят от СУБД — например, IBM-продукты могут не поддерживать это (как @rf15). Спор: Некоторые считают, что эти трюки — не программирование, а администрирование или CLI-навыки (как @ozim и @1vuio0pswjnm7). Спор: Некоторые считают, что трюки устаревают из-за AI — например, @bufordtwain и @monideas считают, что AI делает их менее полезными. Используйте git ls-files вместо find для поиска файлов в репозитории — это быстрее и точнее (как @lucasoshiro). Используйте rg --hidden -g '!*.lock' для фильтрации шума в поиске — это эффективно для повседневной работы (как @ahmedhossamdev). Используйте pbcopy на macOS для копирования вывода команды в буфер обмена — это ускоряет работу с API-ответами (как @okinternets).

Я пережил внутренний кризис, не взрывной, а скорее медленное разрушение уверенности и мотивации — как будто ткань твоего я превратилась в мокрую бумагу после стирки. Причина — генеративный ИИ, который обесценивает труд творцов, превращая их работу в продукт подписки, будто птенца кормят из клюва. В искусстве я всё ещё верю, что ИИ-искусство — это анти-искусство, бездушное и стыдное, но в программировании ситуация тревожнее: почти все инженеры, которых я знаю, сошли с ума за последние годы. Ремесло переживает сдвиг, и каждому приходится выбирать, как реагировать, без подсказок из будущего. Давление сверстников и реальная мощь LLMs делают сопротивление ощущением гонки с движущейся финишной чертой.

Лично мне не нравится программировать с ассистентом: это не весело, результат не кажется своим, и я не горжусь им. Раньше я мог укрыться в своих маленьких проектах — например, в интерактивном переключателе веток git, которым гордился и которым пользовался ежедневно. Теперь такой инструмент можно получить одним запросом, и никто не ценит ручную работу. Мне нужны эти «похлопывания по плечу» от коллег, чтобы чувствовать себя реализованным — и их лишиться больно. То же самое происходит в играх: пост Зака Гейджа о том, что разработка становится похожа на музыку, разрушил меня — годы обучения кажутся напрасными. Потом я поговорил с Шэдом, создателем Uncamera — красивого приложения для iOS, имитирующего плёнку через сенсорные данные и LUT, без ИИ. Его мотивы совпадают с моими: радость в процессе, а не в результате. Он продолжает работать несмотря на сомнения; я же ушёл в саможалость. Но я понял: есть три пути — использовать ИИ и потерять удовольствие, бросить творить (невозможно для творца) или продолжать делать вещи сложным способом, просто потому что это нравится. Я выбрал последнее. Потому что мы делаем игры — и всё остальное — не для результата, а для самого дела.

AI не убивает творчество, а перераспределяет его: кто-то теряет радость от кода, кто-то находит её в новом ритме работы, а другие переходят от написания кода к проектированию систем и управлению сложностью. Многие отмечают, что AI снимает рутину, позволяя сосредоточиться на архитектуре, дизайне и решении сложных проблем, а не на шаблонном коде. Опыт @user43928 показывает ускорение разработки в 10–20 раз: 200k LOC + 100k тестов за 4 месяца без потери качества, опровергая миф о несопровождаемости AI-кода. Спор: @goonersallofyou считает использование AI для генерации кода обманом, как называть себя шефом после заказа еды; @abstractcontrol утверждает, что суть — в понимании проблемы, а не в ручном написании строк. @x3haloed считает, что автор боится изменений и «отстаёт»; @sicktriple и @standfest утверждают, что AI ускоряет рутину, но не заменяет творческое решение сложных задач — в этом и суть. По опыту @blahgeek, AI разделил работу и хобби: на работе он вынужден использовать AI, но только в хобби чувствует радость от чистого творчества — общая тенденция в треде. @Tade0 подтверждает, что полная передача понимания кода AI ухудшает качество: его ревьювер нашёл избыточные переменные, которые AI не смог упростить — необходим человеческий контроль. @saejox и @Aeolun отмечают, что радость от программирования исчезла не из-за AI как инструмента, а потому что «1000 строк кода теперь — это один промпт», убивая ощущение личного вклада. @guiloj использует AI не для замены себя, а для создания инструментов, которые делают его лучше — AI как расширение разработчика, а не замена. @djha-skin использовал AI для документации и скучных функций в проекте на Janet, что усилило его понимание: он бы не написал эти части без AI — инструмент расширил возможности, а не заменил. @rikroots создаёт нишевые инструменты без ожидания коммерческого успеха — мотивация смещается от признания к личному удовлетворению, особенно при перенасыщенности рынка AI-продуктами. @realaleris149 сталкивается с ограничениями AI в интеграции кода и визуальных активов: генерация изображений — одно, их адаптация под игровые механики — другое, и это остаётся человеческой задачей. @wartywhoa23 описывает конфликт между Eros (наслаждение процессом) и Thanatos (желание результата), объясняя, почему одни теряют радость, а другие — находят её в новом ритме. @theplumber отмечает, что AI работает лучше при чётких ограничениях: его инструментарий даёт AI качественные входные данные, делая его эффективным, но не заменяющим разработчика. @ultamatt указывает, что для многих радость от работы — роскошь: реальные проблемы — аренда, здоровье, выживание — и разговоры о «творческом кризисе» звучат как привилегия. @t43562 сравнивает программирование с литературой: если Tolkien писал бы с AI, он бы потерял глубину — ценность в личном, медленном, осознанном творчестве, а не в скорости.

Eric Selin создал statichost.eu — полностью европейский хостинг для статических сайтов, где каждый элемент стека, от деплоя через Git до CDN, работает на инфраструктуре, принадлежащей европейским компаниям. Он отказался от использования американских сервисов вроде AWS и Cloudflare, считая, что доверие данным и контроль над инфраструктурой должны оставаться в Европе. Проект возник из разочарования в «европейских» хостингах, которые фактически полагаются на американские облака.

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

Обсуждение подтверждает, что Statichost.eu закрывает потребность в европейском хостинге, но вызывает критику из-за высоких цен, непрозрачных тарифов и технических ограничений, несмотря на положительный опыт с бесплатным планом и поддержкой. **Критика цен и модели** - @gbxbxbcbd: 120 EUR/год за безлимитные сайты и дорогой трафик невыгодны — аналогичный VPS на Scaleway стоит 5 EUR с безлимитным трафиком. - @FabCH, @sparkling: 9 EUR/мес за статический хостинг — слишком дорого; за ту же цену можно взять VPS с безлимитным трафиком в Европе. - @dlahoda иронично перечисляет «европейские ценности» как бюрократические барьеры (налоги, карта, резиденция, цензура), намекая на политическую избыточность. **Прозрачность и доверие** - @jonplackett: плохой дизайн сайта (неадаптивное меню, несогласованное оформление) подрывает доверие. - @reconnecting: страница статуса отправляет данные в Google и DoubleClick, что противоречит заявлению об отсутствии сбора персональных данных. - @sajithdilshan, @palata: в документации нет информации об объёме хранилища и автоматической генерации TLS-сертификатов. - В то же время @g-b-r и @exitnode хвалят краткие и понятные условия использования. **Технические ограничения** - @chrisjj, @mtlynch: отсутствие rsync-подобной синхронизации и обязательная сборка (build minutes) — неоправданные ограничения для статических сайтов. - @archonis: нет аутентификации по SSH-ключу, что снижает безопасность и удобство. **Положительный опыт и предложения** - @exitnode, @thih9: сервис работает стабильно, быстро и бесплатно — хороший вариант для небольших сайтов без сложных сборок. - @jeremyjh предлагает интегрировать Statichost.eu с Codefloe (европейский Git-форж) для решения проблемы с управлением версиями. - @throwfaraway135 выражает недоверие к EU-юрисдикции, допуская цензуру, что ставит под сомнение «европейские ценности» как гарантию свободы.

OpenAI Codex (переименованный в ChatGPT Desktop) хранит в ~/.cache/codex-runtimes/codex-primary-runtime 1,7 ГБ данных, включая полные установки Python и Node.js, а также нативные бинарники Poppler, git и LibreOffice. Последний занимает 429,7 МБ в виде libreoffice-headless, что позволяет приложению обрабатывать документы без графического интерфейса. Эти компоненты находятся в подпапке dependencies, а их использование настраивается через навыки (skills) в plugins/documents, где указано, как вызывать нужные бинарники для работы с файлами. Такой подход делает Codex самодостаточным инструментом для работы с кодом и документами, избавляя пользователя от необходимости отдельно устанавливать зависимости. Включение LibreOffice указывает на фокус на обработке офисных форматов (DOCX, ODT и т.п.) напрямую из кэша приложения. Всё это подтверждает стратегию глубокой интеграции системных инструментов внутрь desktop-клиента для расширения его возможностей за чистый LLM-интерфейс.

LibreOffice включён в ChatGPT Desktop для надёжной обработки устаревших форматов (DOCX, XLSX) в headless-режиме — по опыту @esperent, альтернативы такой надёжности не дают. Размер зависимостей (1.7 ГБ) воспринимается как избыточный bloat (@cpursley, @pseudosavant); @quotemstr предлагал загрузку по требованию, но @esperent полагается на гарантированную доступность. @jav-8448 и @gfalcao указывают на отсутствие упоминания лицензий в приложении, что ставит под вопрос соблюдение MPL 2.0; @pocksuppet считает, что явного требования к этому нет. Среди предложений: переписать LibreOffice на Rust (@devy), использовать Vespper.com для редактирования DOCX (@topaztee). Приложение не проверяет системные бинарники (@mirzap), не предоставляет доступ к транскрипции аудио (@Lucasoato), лишено глобального горячего ключа (@RestartKernel) и нагружает CPU на Windows (@robomartin). Включение связано с ChatGPT Work — продуктом для генерации и редактирования документов (@zitterbewegung, @wilg).

AI-сканеры создают постоянную нагрузку на git.kernel.org, потребляя около 20% вычислительных ресурсов — 14–16 из 90 ядер на пяти узлах постоянно тратятся на рендеринг коммитов в HTML для обучения моделей, что превышает нагрузку от всех легитимных запросов, включая git clone. Причина — неэффективный метод сбора данных: вместо простого клонирования репозиториев сканеры запрашивают каждый коммит как отдельную HTML-страницу, генерируя миллиарды дублирующих URL из-за форков и параметров вроде diff и patch, что создаёт «фоновое излучение» нагрузки. Хотя сайт остаётся отзывчивым для людей, основные сбои вызывают не сканеры, а плохо спроектированные CI-системы с поверхностными клонами. Администраторы пытаются бороться блокировкой IP и подсетей, но боты маскируются под браузеры и распределяются по облакам. В долгосрочной перспективе планируется ограничить функциональность и сократить количество сканируемых URL, хотя это ухудшит доступ для анонимных пользователей. Все данные останутся доступны для загрузки, но с дополнительными барьерами. Проблема системная: пока спрос на обучающие данные для LLM растёт, а простых решений нет.

Обсуждение дополняет статью: проблема не в технической неэффективности, а в системном провале этики веб-скрапинга. AI-скраперы игнорируют robots.txt и rate limiting, а защита через proof-of-work вредит легитимным пользователям, не останавливая продвинутых ботов. Советы по противодействию: - Замена Anubis на кастомную хеш-функцию без публикации обходит ASIC-скраперы, заточенные под стандартную реализацию. - Отказ от публичного HTML-интерфейса в пользу git clone для всех и веб-интерфейса только для авторизованных пользователей. - Лимит неавторизованных запросов — 5 в минуту с разрешением высокой частоты для авторизованных. - Рендеринг HTML на клиенте через JS-клиент, который клонирует репозиторий в браузере и кэширует данные. - Ловушки (бесконечные пути, медленная передача изображений, генерация абсурдного контента) заставляют ботов тратить ресурсы впустую. - Whitelist по IP/ASN вместо blacklist с общим списком между сайтами (риск: рынок поддельных доверенных узлов). - Повышение стоимости доступа к старым коммитам относительно новых — легитимные пользователи редко запрашивают древние данные. - Превращение proof-of-work в добровольный майнинг криптовалюты, где боты «платят» хостингом. - Временное повышение сложности Anubis при запросах к нестандартным URL с подсказкой посетить главную страницу. - Кэширование HTML-рендеров git-репозиториев, так как коммиты редко меняются. - Блокировка cgit-эндпоинтов (diffs, blame, snapshots) и возврат 402 за доступ — признание поражения, но единственный рабочий способ остановить ботов без отключения сервиса. Споры: - Anubis неэффективен: скраперы обходят его через куки, а мобильные пользователи страдают от высокой сложности. - AI-скраперы тратят ресурсы на обучение, но это не оправдание — они могли бы клонировать репозитории, а не запрашивать каждый коммит в HTML. Консенсус: - Современные AI-скраперы игнорируют robots.txt, rate limiting и другие устоявшиеся практики, делая традиционные методы защиты бесполезными. - Рост нагрузки от ботов не связан с качеством контента: скраперы сканируют всё подряд без фильтрации, создавая комбинаторный взрыв URL.

Авторы ежедневно собирают и анализируют лексику из GitHub Pull Requests, чтобы выявить устойчивые паттерны в языке разработчиков. За 595 дней обработано более 461 тыс. PR и 51 млн слов, которые с помощью KL-дивергенции и k-means разбиты на 10 кластеров лексики. Один из кластеров, появившийся в 2026 году, доминирует в 40% всех PR, приписанных людям, за последний месяц, и его характерные слова напрямую связаны с использованием coding-агентов, таких как Claude Code.

Среди самых репрезентативных терминов этого кластера — load-bearing, refusal, survives, byte-identical, mutation-tested, structurally indistinguishable и другие, отражающие акцент на формальной верификации, неизменяемости и доказательной корректности кода. Эти слова указывают на сдвиг в практике разработки: всё больше PR фокусируются не на функциональности, а на гарантиях, которые код предоставляет — например, что изменение не ломает поведение, сохраняет битовую идентичность или выдерживает формальную проверку. Такой словарь стал «несущей конструкцией» современного кода, написанного с помощью ИИ-ассистентов.

Тред подтверждает наблюдаемость «клоудизмов» в проде и расширяет картину за пределы лексики: отмечаются синтаксические и форматные паттерны, проникновение в человеческую речь, гипотеза о компаундинг-эффекте при обучении новых моделей на AI-контенте, и практические попытки подавлять стиль через системные промпты. Отдельные респонденты считают часть слов обычным техжаргоном и оспаривают тезис о чисто LLM-происхождении слов типа load-bearing.

• Многие подтверждают из опыта, что «load-bearing», «spike», «sidecar», «resolver», «crux», «first-class citizen» массово появились в их кодовой базе и PR вместе с распространением Claude; @legobmw99 отмечает, что «sidecar» по их поиску стал использоваться в 3.6x чаще.

• LLM-лексика перетекает в человеческую речь: @nater5000 и @MrDrDr признаются, что стали непроизвольно использовать LLM-конструкции в своей письменной речи.

• Проблема выходит за лексику — синтаксис и формат тоже сигналят: @stabbles указывает на оборот «X contains no Y», @iamacyborg — на тирады с «, and», «, because», @elias_junit — на подчёркнуто линейную, хорошо структурированную подачу вместо нелинейного нарратива.

• Спор: Часть участников (@sethd, @danpalmer, @sosull) считает, что «Claude-измы» — это обычный техжаргон или следствие того, что модель буквально опирается на эти слова как на носители концептов (без них хуже думает), а @SalariedSlave и @polycaster, наоборот, видят именно LLM-специфичное явление и подозревают компаундинг-загрязнение обучающих данных.

• Совет: @ben30 показывает работающий приём: в глобальный промпт добавлено правило Орвелла и явный запрет на «load-bearing», «the crux», «first-class citizen»; в ответ Claude сам сообщает, что его системные инструкции требуют помечать «что-то load-bearing», то есть ограничение реально режет инструкции модели.

• Совет: @jimbobimbo использует в инструкциях агентов «find a synonym to 'resolve'», иначе появляется класс Resolver с методами ResolveThis/ResolveThat; @prmph заводит список запрещённых слов и просит переписать текст понятнее.

• Переломным по ощущениям @datadrivenangel называет примерно апрель (Opus 4.6/4.7), после чего Claude стал казаться «другим и более неудобным». @whywhywhywhy удивлён отсутствию в топе слова «shape».

• Подача проекта высоко оценена UX-составляющая: @nater5000 и @sosull хвалят, что всё помещается на экран без лишней воды, @Labo333 (автор) отвечает, что бэкенда нет — обновление и анализ делаются через GitHub Actions; обещает увеличить выборку до 1000 PR/день и поисковую строку.

Orwell's first rule: never use a metaphor you're used to seeing in print. "Load-bearing", "the crux", "first-class citizen" signal insight instead of showing it. Name the specific mechanism — @ben30

GitHub столкнулся с перебоями в работе некоторых сервисов, включая проблемы с доступом к репозиториями, пуш-операциями и вебхуками. Инцидент был зафиксирован в статусе «Resolved» после устранения неполадок, связанных с внутренними компонентами платформы. Пользователи сообщали о задержках и ошибках при выполнении Git-операций и взаимодействии с API, что указывало на сбой в инфраструктуре, отвечающей за обработку запросов.

Компания подтвердила, что инцидент был полностью устранён, и обещала опубликовать детальный анализ причин в ближайшее время. Для предотвращения повторения таких ситуаций GitHub рекомендует подписаться на уведомления через статуc-страницу, чтобы получать оперативную информацию о будущих инцидентах по email, SMS, Slack или вебхукам. Восстановление сервисов произошло без потери данных, и платформа вернулась к нормальной работе.

Тред дополняет статью двумя вещами: статистически фиксирует нисходящий тренд аптайма GitHub в августе (@mrshu) и превращает одиночный инцидент в паттерн «нормализации сбоев», при котором реальные пользователи (@xbryanx, @Traubenfuchs) уже мигрируют на Forgejo/самохост, а критика архитектуры (@everfrustrated, @lossolo) указывает на отсутствие шардинга и привязку к upstream-Vitess как на структурные, а не разовые причины.

• Несколько комментаторов (@tomw1808, @theanonymousone, @jp_sc, @CerebralCoding) сходятся: регулярные сбои GitHub уже нормализовались, и шутки формата «должно быть, день на Y / среда» отражают усталость, а не удивление.

• @nr378, @Traubenfuchs и @xbryanx сходятся в требовании разделить инфраструктуру платных и бесплатных пользователей на уровне архитектуры, а не только тарифа.

• Спор: @tomw1808 считает «просто смирились — это ненормально для критического сервиса и заслуживает кредитов», тогда как @rglover добавляет, что проблема в раздутии сложности и призываeт к выделению GitHub из Microsoft обратно в независимую компанию — спор о том, лекарство это регуляция SLA или деконсолидация.

• Спор: @guhcampos предлагает ту же модель «решить через rate limit на бесплатных аккаунтах», а @rglover и @inigyou противопоставляют: проблема не в нагрузке free-tier, а в спагетти-архитектуре; @everfrustrated усиливает — single primary без шардинга аматорство для такого масштаба.

• Совет: @xbryanx делится опытом: во время прошлого сбоя развернул Forgejo с кастомными action runners и сегодня завершает миграцию — практическая точка перехода для команд с GitHub Actions.

• Совет: @guhcampos предлагает как быстрое лекарство: rate limit на git-команды для free-аккаунтов, считая, что никому не нужны множественные push в минуту, и это снизит нагрузку на downstream-триггеры.

• Совет: @stalfosknight и @thatwasunusual формулируют запрос на обзор альтернатив по состоянию на август 2026; @rvz даёт ссылки на обсуждения двух предыдущих инцидентов с Actions за 5 дней и на постмортем, превращающий сбой в рекуррентный сигнал.

• @mrshu публикует график: исторический аптайм улучшался, но в августе идёт нисходящий тренд — количественное подтверждение ощущения «сбоев стало больше».

• @everfrustrated, @lossolo и @mportela критикуют архитектуру: один primary для БД без шардинга, отсутствие хоризонтального масштабирования для Git и Actions, упавший до «одной девятки» аптайм — противопоставляют это четырём-пяти девяткам, к которым стремились раньше.

• Совет: @Elfener документирует неочевидный side-effect: «github-merge-queue Bot removed this pull request from the merge queue due to no response for status checks» — конкретный артефакт сбоя в merge queue, полезный для диагностики у себя.

• Совет: @zackify и @Traubenfuchs указывают, что self-hosted runners не спасают, потому что падает и core-инфраструктура Actions, а не только managed runners — сужает пространство «страховок».

• @sandermvanvliet публикует расширение gh-omens, проверяющее статус GitHub перед использованием, и @frenchie4111 отмечает, что браузер уже автоподставляет githubstatus.com по «gith» — индикатор, что статус GitHub читают как погоду.

This is why it's hard to take GitHub seriously. How can a single database cause an outage for everyone? This is amateur stuff. Have they no sharding or partitioning internally? Paying customers should not be impacted in the same way as free ones are. — @everfrustrated

Графенос OS — это специализированный сервер Mastodon, предназначенный для официальных аккаунтов проекта и его разработчиков. На нём нет привычных поисковых функций и статистики; сервер обслуживает лишь небольшое сообщество из четырёх активных пользователей.

Ключевой факт: Google заменил выдачу Git‑тегов для некоторых репозиториев на загрузку исходников через Google Drive, сделав процесс крайне затягивающим и неудобным. Это нарушает GPLv2, которая требует предоставления исходного кода по «обычному для программного обеспечения» каналу в разумные сроки, а не через архаичную систему с длительными задержками.

Главное запомнить: использование Google Drive вместо Git‑тегов — явное нарушение лицензии и пример того, как крупные корпорации усложняют доступ к открытым исходным кодам.

Google намеренно усложнил доступ к исходному коду Pixel-устройств, отказавшись от публикации Git-тегов в AOSP и перейдя на ручной запрос через Google Drive. Это нарушает дух GPLv2 — формально код предоставляется, но автоматизация, CI/CD и своевременное исправление уязвимостей становятся невозможными. Регулярные релизы для Pixel прекратились, вынудив GrapheneOS искать альтернативы, включая партнёрство с Motorola. Адаптация к новой системе заняла недели, подтверждая системный, а не случайный характер изменений. Доступ через Google Drive требует ручного взаимодействия, в отличие от прямых ссылок у других проектов, что делает его непрактичным и противоречащим сути лицензии. Некоторые оправдывают это бюрократией или лицензионными ограничениями, но другие видят в этом целенаправленную стратегию по закрытию экосистемы — включая планы по блокировке sideloading. Сравнение с Microsoft, отправляющей код за $5 по почте, показывает, что Google создаёт более высокие барьеры. Потеря доверия со стороны сообщества подтверждается переходом GrapheneOS к другим производителям. Отказ от публикации тегов позволяет только Google воспроизводить точные сборки, снижая прозрачность. Google, будучи одной из крупнейших ИИ-компаний, противоречиво сочетает инвестирование в технологии с уничтожением открытости Android, копируя модель Apple. Отсутствие доступа к исходному коду ставит под угрозу безопасность пользователей. Некоторые считают, что Red Hat нарушает GPLv2 серьёзнее, но это не оправдывает действия Google. Пользователям и разработчикам следует поддерживать альтернативы и требовать отказа от Google-ограниченных драйверов — иначе свободная экосистема Android умрёт.

Код теперь можно размещать напрямую в 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.

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

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

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

Decker — это платформа для создания интерактивных мультимедийных документов, вдохновлённая HyperCard и визуальной эстетикой классического macOS. Она сочетает простоту и доступность старых инструментов с современными удобствами: глубокой историей отмен, поддержкой сенсорных экранов, масштабируемыми операциями и полноценным скриптованием. Пользователи могут создавать электронные журналы, презентации, текстовые приключения, пиксель-арт или просто экспериментировать — всё сохраняется в самодостаточных HTML-файлах, которые работают в браузере и совместимы с Git. Деки — это не просто документы, а наборы переиспользуемых компонентов, которые легко копировать и адаптировать.

Для сложной логики используется язык Lil — лёгкий, похожий на Lua и Q, с неожиданными удобствами: неявной арифметикой векторов, встроенным SQL-подобным запросом и минимальной кривой обучения. Lil работает и вне Decker через Lilt — автономный интерпретатор, который можно скомпилировать в один исполняемый файл и запустить даже в AWK. Все файлы хранятся в текстовом формате, что делает их идеальными для версионного контроля. Decker лишён рекламы, телеметрии и навязчивых функций — он создан для творчества, а не для монетизации. Среди примеров — Sokoban, Breakout, CHIP-8-интерпретатор и библиотеки для анимации, звука, графиков и визуальных новелл. Платформа открыта под MIT-лицензией, с активным сообществом и ежегодными джемами.

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

Колонка — это пустая команда, которая ничего не выводит, но позволяет применять расширенный синтаксис параметрического расширения ${name:?msg}. Вместо четырёх строк проверки обязательных параметров её можно заменить на : "${1:?missing argument, aborting.}", а для переменных задавать значения по умолчанию через : "${DATA_DIR:=/var/data}". Она также служит для обнуления файлов — : > error.log, а комбинация : > error.log > access.log одновременно очищает несколько файлов. Благодаря этому скрипты становятся короче и читабельнее, а диагностическое сообщение содержит имя переменной.

Помимо проверок, : используется как placeholder, где синтаксис требует команду, но действие не нужно. Например, ( : < dataset.json ) && echo YES проверяет читаемость файла, а ( : >> result.json ) && echo YES — его записываемость. В обработке сигналов её можно задать в trap : INT, делая прерывание безопасным. В Git‑ алиасах её применяют для интерактивного rebase: riq = -c sequence.editor=: rebase --interactive. Исторически : восходит к 1971‑му Thompson‑shellу, где оно было меткой и первым комментарием; сегодня его называют «двумя глазами, полными любви», подчёркивая простоту и мощь этого простого символа.

Тред обсуждает использование колона в shell-скриптах: некоторые считают его вредным для читаемости и поддержки, другие — полезным для сокращения кода. @olexsmir рекомендует его для установки значений по умолчанию: `: ${DOTFILES_PATH:=$HOME/.dotfiles}`. @kps предлагает применять колон для форматирования вывода команд, упрощая копирование. @orphereus и другие критикуют колон как излишнее усложнение и признак плохого дизайна языка, предлагая ограничить его использование.

Мы находимся в центре искусственного‑интеллекта психоза: модели ускоряются, программисты увольняются, обещают, что к концу года искусственный интеллект напишет сто процентов кода, но при этом качество обычных приложений падает. Примеры из недели: банковское приложение требует трёх FaceID‑входов перед три‑разовым протоколом, Slack на macOS крадёт фокус у Ghostty и отправляет git pull в чат, холодильник LG выдаёт ошибку при гарантийном запросе, а авто‑инфо‑система после обновления глючит: звук поворота исчезает, Google Maps открывается вместо радио, задержка в секунду перед реакцией.

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

Пользователи отмечают снижение качества ПО, связывая это не столько с ИИ, сколько с отсутствием стимулов к качеству, чрезмерной сложностью и давлением на быстрое развитие. Некоторые предлагают решения: использование LTS-дистрибутивов Linux, фокус на надёжности и упрощение интерфейсов.

В предстоящем созыве 2026 года официально предложено полностью запретить любые проекты, связанные с криптовалютами, чтобы исключить их из официального программного пакета. Обсуждение собрало семь участников: Gusted, camopants, Johnny, -k, nekogirl, exidot и johnoestmannmusic. В задаче, размещённой в системе Codeberg, нет описания, но в ней указаны метки «No reviewers», «No milestone», «No assignees», «No due date» и «No dependencies», что подчёркивает отсутствие готовой оценки, планируемого срока и ответственных. Ссылка на задачу приводится как Codeberg/org!1254, а в ней перечислены участники с их аватарами, что делает процесс полностью открытым и прозрачным.

Один из участников инициировал удаление ветки «gusted/2026-assembly-cryptocurrency», предупредив, что такой шаг является окончательным и неотменяемым в большинстве случаев. При удалении ветка может существовать лишь короткое время в кэше, после чего исчезнет полностью, что делает отмену невозможной. Удаление фиксируется как постоянное действие, и восстановление ветки обычно невозможно, поэтому участники должны быть уверены в необходимости такого решения. По данным обсуждения, семь участников поддержали инициативу, а отсутствие ревьюеров подчёркивает отсутствие готовой проверки. Это усиливает аргументы в пользу полного запрета. Таким образом, проект будет полностью исключён из официального списка.

Пользователи считают запрет криптовалютных проектов на Codeberg неправильным решением, видя в нём цензуру, которая может подорвать репутацию платформы и привести к дальнейшим ограничениям. Другие оправдывают его необходимостью обеспечения безопасности и целостности платформы. Рекомендуется использовать альтернативы — Gitea или Forgejo.

Cursor содержит критическую уязвимость, позволяющую выполнить произвольный код при открытии репозитория с вредоносным файлом git.exe в корне — без каких-либо предупреждений или действий пользователя. Уязвимость проста, но опасна: IDE автоматически запускает этот файл, игнорируя безопасность. Учитывая, что Cursor используют более 7 млн активных пользователей и 50 тыс. компаний, а его оценка достигает $60 млрд, отсутствие реакции на уязвимость, обнаруженную в декабре 2025 года, вызывает серьёзные вопросы.

Mindgard неоднократно сообщал о проблеме через официальные каналы, включая security.txt и HackerOne, но Cursor игнорировал сообщения в течение семи месяцев, несмотря на подтверждение уязвимости и повторные запросы. Только после публичного давления компания признала сбой в автоматизированной системе, но не предприняла действий по исправлению. В ответ исследователи решили раскрыть детали — чтобы защищать пользователей, когда разработчик отказывается это делать. Для защиты рекомендуется блокировать выполнение исполняемых файлов в рабочих каталогах через AppLocker или использовать изолированные среды.

• LLM‑сгенерированные отчёты перегружают команду, их сложно отсеять без риска пропустить реальные проблемы
• Cursor по умолчанию не проверяет рабочее пространство, что позволяет выполнить произвольный код из репозитория (например, git.exe)
• Уязвимость связана с особенностью Windows, когда текущая директория имеет приоритет в поиске исполняемых файлов
• Публичное раскрытие вызвало споры о ответственности разработчиков и необходимости более строгих механизмов доверия

Экспериментальная подкоманда git history, появившаяся в версиях 2.54 и 2.55, предлагает три способа переписывания истории без риска поломки дерева. fixup позволяет поправить старый коммит, включив в него подготовленные изменения, и автоматически переписать все локальные ветки, построенные на его основе, сохраняя атомарность и отказываясь от операций, которые могут вызвать конфликт. При этом она не работает с merge‑коммитами, что ограничивает применение, но открывает путь к будущим улучшениям. Это особенно ценно, когда несколько веток используют один и тот же баг‑фикс, потому что исправление автоматически поднимается по всем зависимым ветвям.

reword меняет сообщение коммита и перестраивает всё, что находится над ним, без вмешательства в индекс или рабочее дерево, позволяя править сообщения даже в удалённых ветках. split делит один коммит на два, интерактивно выбирая части изменений, что упрощает разбиение крупного коммита без сложных rebase‑ов. Обе команды сохраняют целостность истории, а их главное преимущество — возможность применять изменения к любой ветке без её проверки, что делает их практичным альтернативным инструментом, сравнимым с более новым jj, но полностью встроенным в Git. Кроме того, split позволяет интерактивно разбивать изменения на отдельные части, не требуя сложных команд git add -p.

• Понимание внутреннего устройства Git (например, через Pro Git) упрощает работу с rebase и другими командами.
• Новые инструменты (git history fixup, git history split) упрощают изменение истории, но работают только без конфликтов.
• Автоматизация ребейза и рефиксаций может привести к «поломке» дерева, поэтому важно знать способы отката (git reset --hard, git reflog).
• Хорошо отредактированная история (одна логическая правка на коммит) облегчает поиск багов, регрессий и ревью, в отличие от полного сжатия изменений.

В Git существует три отдельных механизма для исключения файлов, работающих на разных уровнях. Основной — .gitignore, который хранится в репозитории и попадает в коммит; второй — .git/info/exclude, локальный для конкретного репозитория и не версионируется; третий — глобальный файл ~/.config/git/ignore, действующий для всех репозиториев на машине. Благодаря этому можно игнорировать как общие артефакты (например, .DS_Store), так и личные временные файлы, не засоряя .gitignore.

Для проверки, какой из файлов игнорирует конкретный путь, используется git check-ignore -v <файл>. Если правило берётся из .gitignore, вывод выглядит как .gitignore:1:.DS_Store .DS_Store; из .git/info/exclude — .git/info/exclude:7:.DS_Store .DS_Store; при использовании пользовательского глобального файла — /Users/nelson/.gitignore_global:1:.DS_Store .DS_Store. Если ничего не игнорирует файл, команда ничего не выводит. Кроме того, глобальный файл можно задать под другим именем, например .gitignore_global, командой git config --global core.excludesFile ~/.gitignore_global, а вернуть стандартный режим — git config --global --unset core.excludesFile. Это удобно, если хочется хранить отдельный набор правил, например, исключать все файлы с расширением .log или каталог build. Таким образом, гибкость игнорирования расширяется за пределы обычного .gitignore.

• .gitignore — обычный способ игнорировать файлы в репозитории, но его нельзя использовать для игнорирования глобально на всех проектах.
• Существует глобальный игнор‑файл (~/.config/git/ignore или ~/.gitignore_global), который игнорирует файлы для конкретного пользователя, а не для всей машины.
• Для локального игнорирования без изменения репозитория можно использовать .git/info/exclude или файл в .git (например, scratch/.gitignore с *).
• Иногда полезно добавить правила в .gitattributes (например, игнорировать package-lock.json) или использовать git update-index --assume-unchanged/--skip-worktree для временного отслеживания файлов.

GitHub сообщает о сбоях в операциях Git, влияющих на работу сервиса. Пользователи могут столкнуться с проблемами при выполнении Git-команд, хотя другие функции платформы могут оставаться доступными. Компания рекомендует следить за официальными каналами для получения актуальной информации о статусе восстановления.

Для отслеживания инцидента GitHub предлагает несколько способов уведомлений: email, SMS, интеграция со Slack и вебхуки. Пользователи могут настроить подписку на получение оповещений о создании, обновлении или решении инцидентов. Для подтверждения подписки требуется ввод OTP (одноразового пароля), а при выборе SMS-уведомлений доступен выбор страны и ввод телефонного номера.

• Массовые жалобы на сбой GitHub: проблемы с push/pull, Actions, raw.githubusercontent.com и SSH-аутентификацией.
• Рост обеспокоенности надёжностью облачных сервисов (AWS, GCP, Azure, GitHub), сбои происходят чаще.
• Критика централизации и приоритетов компаний: упрёки в пренебрежении инфраструктурой ради AI/прибыли.
• Поиск решений: рекомендации по самохостингу (Forgejo, Gitea), локальным кешированию git и отказу от полной зависимости от SaaS.
• Спекуляции о причинах: влияние AI на инфраструктуру, "vibe coding", общая хрупкость централизованных систем.

Автор случайно обнаружил 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, каждый из которых имеет свои сильные стороны и может быть полезен в различных ситуациях.

В работе с monorepo, где ежедневно делаются сотни коммитов, тесты внезапно начали проваливаться. Проблема была в изменении конфигурационного файла, который ссылался на неверный аккаунт, но найти виновника среди множества коммитов вручную было невозможно. Тогда коллега применил git bisect - инструмент, использующий бинарный поиск для локализации проблемного коммита. Это позволило точно определить, где именно был внесен сбойный код, после чего откат этого коммита восстановил работоспособность системы.

В статье приведен наглядный пример репозитория с функцией сложения, где намеренно введена ошибка - преобразование аргументов в строки. Запуск git bisect start, указание "плохого" и "хорошего" коммитов, затем git bisect run ./test_script.sh автоматически проверяет промежуточные версии. Инструмент последовательно тестирует коммиты, сокращая количество проверок вдвое на каждом шаге, и точно находит первый сбойный коммит, где функция add начала возвращать строку вместо числа.

• git bisect is a powerful tool for pinpointing the exact commit that introduced a bug, especially in large or poorly tested codebases.
• Its real value is in narrowing the search space when you lack the tests or architecture to reason about the code, not in replacing proper testing or code review.
• The discussion exposed a cultural divide: some developers see bisect as a last-ditch rescue tool for when tests or architecture have already failed, while others argue that if you need it, your process has already failed.
• Several commenters pointed out that if you have to reach for bisect, you probably lack tests, logging, or a clear commit history, and the real fix is to improve those, not to rely on bisection.
• The thread also surfaced the point that bisection is only useful if you can reliably detect the bug in every commit; if the bug is non-deterministic or only shows up in production, the tool becomes much less useful.

Автор активно использует 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 и других инструментов, обсуждают их преимущества и недостатки, а также их влияние на разработку и рабочий процесс.
• Обсуждаются проблемы с контекстом, который может использовать агент, и как лучше всего структурировать проекты для облегчения работы агента.
• Также затрагивается вопрос о том, как лучше всего использовать инструменты в зависимости от ситуации и как они могут быть улучшены.

Любой сервер с SSH-доступом может стать Git-сервером. Достаточно клонировать репозиторий через git clone ssh://username@hostname/path/to/repo, а для отправки изменений добавить на сервере git config receive.denyCurrentBranch updateInstead. Этот подход идеален для синхронизации кода между устройствами или работы с файлами на сервере без задержек.

Для публикации кода через веб нужно указать веб-серверу путь к Git-репозиторию и выполнить git update-server-info. Чтобы это происходило автоматически, можно настроить хук post-update, который будет запускать эту команду после каждого обновления. Хуки также могут использоваться для запуска статических генераторов сайтов — автор блога успешно применяет этот метод для своего сайта, получая преимущества локальной работы и автоматического развёртывания.

Такой подход обеспечивает встроенное резервное копирование: при поломке сервера данные останутся на ноутбуке, и наоборот. Git-трекинг версий предотвращает случайные удаления и упрощает отладку ошибок.

• Обсуждение охватило широкий спектр тем: от фундаментальных концепций (bare-репозитории, push-в-в-ssh, хуки) до практических аспектов (самостоятельный хостинг, CI/CD, бэкапы).
• Участники подчеркнули, что Git изначально задумывался как распределённая система без необходимости в централизованном хостинге, и что это встроено в его архитектуру.
• Были упомянуты различные инструменты и практики, такие как git init --bare, git daemon, git-shell, хуки и т.д., как часть более широкого обсуждения о том, как Git может быть использован для хостинга репозиториев.
• Обсуждались также более широкие темы, такие как философия open-source, централизация против децентрализации, и как GitHub/GitLab и подобные платформы влияют на разработку ПО и сообщество.

В 2012 году автор, работая с Ruby и Rails, обнаружил Rust и увидел в нём потенциал. Он оценил три ключевых фактора успеха языка: рыночную нишу (безопасность памяти без сборщика мусора как инновация в низкоуровневом программировании), команду (поддержку Mozilla) и пользователей (планы использовать Rust в Firefox). Этот подход помог ему принять решение присоединиться к проекту Rust, написать руководство "Rust for Rubyists" и в итоге войти в команду.

Сейчас автор применяет тот же анализ к jj — новой системе контроля версий, написанной на Rust. Как и в случае с Rust, он видит у jj хорошую рыночную нишу (возможность работать с Git-репозиториями для постепенного внедрения), сильную команду (Google использует jj) и растущую пользовательскую базу. На первой конференции jj создатель马丁 отметил важный аспект, хотя детали в статье не раскрываются.

• Обсуждение в основном вращается вокруг того, что Git остаётся доминирующим, но jj и другие инструменты могут предложить улучшенный UX и модель данных, что делает их привлекательными для некоторых пользователей.
• Участники обсуждали, что отсутствие интеграции с GitHub и другими платформами может быть препятствием для широкого внедрения jj.
• Некоторые участники выразили обеспокоенность относительно того, что новые системы могут не поддерживать критические функции, такие как LFS и инструменты для работы с бинарными файлами.
• Обсуждались также вопросы документации, обучения и поддержки сообщества, которые могут быть недостаточными для новых систем.
• Наконец, обсуждались личные мотивации и карьерные шаги, включая влияние на открытый исходный код и его влияние на развитие инструмента.

Разработчики Zed анонсировали полноценную версию редактора кода для Windows. Теперь он доступен как в стабильной, так и в тестовой версии, причём последняя обновляется еженедельно. Zed на Windows использует DirectX 11 для рендеринга и DirectWrite для рендеринга текста, что обеспечивает нативное соответствие платформе.

Ключевая особенность — глубокая интеграция с WSL и SSH: пользователи могут открывать папки из WSL прямо в Zed, а все операции I/O происходят через удалённое соединение. Это распространяется на все функции, включая работу с Git, терминалами и отладчиками.

Расширения Zed, основанные на WebAssembly, работают на Windows без дополнительных настроек. Они изолированы через WASI, что обеспечивает безопасность и прозрачность работы с файлами.

Команда призывает пользователей тестировать Zed на Windows, особенно в контексте WSL, различных мониторов и сложных конфигураций клавиатур. Отзывы помогут ускорить фиксацию багов и улучшение платформы.

• Основные проблемы: отсутствие DevContainer, медленный LSP-ответ, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки

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

• автоматически создают git-worktree для изолированной работы над задачей;
• ведут диалог с агентом, пока тот не сформулирует план и начнёт реализацию;
• разбивают задачу на подзадачи и делегируют их суб-агентам;
• проводят код-ревью каждого PR.

Самое важное — это набор «скиллов» в формате Markdown, которые обучают модель, как обращаться с конкретными инструментами. Скиллы можно писать вручную, но проще сказать «прочитай и выпиши скиллы из книги X». Это поднимает вопросы об IP, но пока что это внутреняя кухня Anthropic, вопросы пока остаются открытыми.

Проект называется Superpowers, и он уже доступен как плагин для claude-code.

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

Tangled — это новая платформа для совместной работы с Git, построенная на AT Protocol. Вместо централизованных серверов она предлагает «узлы» — лёгкие headless-серверы, которые можно поднять на Raspberry Pi. Узлы могут быть как однопользовательскими, так и мультитенантными, а весь «интерфейс» консолидируется в единое веб-приложение на tangled.sh. Проект декларирует три принципа: полный контроль над данными, низкий порог входа и не вмешательство в UX. Пока что доступ осуществляется по инвайтам в IRC-канале #tangled на libera.chat.

• Обсуждение вращается вокруг трёх тем: децентрализация, монолитные платформы vs. модульные сервисы и экономика открытого исходного кода.
• Участники обсуждают, как сделать git более децентрализованным, но при этом не теряя удобства и не создавая барьеров для входа.
• Обсуждается, как избежать блокировок и цензуры, и как при этом не терять удобство и не платить за хостинг.
• Также поднимается вопрос о том, как избежать vendor lock-in и как при этом не терять удобство и не платить за хостинг.

Разработчик случайно удалил рабочий код, который улучшал метрики ML-модели на 5%, и не смог его восстановить. Вместо git он использовал LLM с контекстом в 1 млн токенов, которая сохранила историю взаимодействий. Просто запросив исходную версию файла, он мгновенно вернул потерянный код. Это демонстрирует неожиданное преимущество больших контекстных окон — они действуют как автоматический журнал изменений, компенсируя человеческие ошибки.

• Критика использования ИИ как замены систем контроля версий (Git) из-за риска потери или повреждения кода.
• Подчеркивание важности регулярных коммитов в Git и использования функций локальной истории IDE для сохранения работы.
• Обсуждение технических ограничений ИИ, таких как ошибки в воспроизведении кода и непонимание контекста, даже при больших размерах контекстного окна.
• Упоминание о том, что некоторые инструменты ИИ (например, Gemini CLI) могут хранить данные для отката изменений, но это не надежная замена VCS.
• Восприятие исходной истории как юмористической или саркастической, но с предупреждением о серьезных последствиях подобных практик.

Код-ревью часто превращается в формальность из-за слишком больших и сложных пул-реквестов. Разработчики избегают глубокого анализа, ограничиваясь поверхностными комментариями, что ведёт к накоплению технического долга и уязвимостей. Ключевое решение — нормализовать возврат непонятных PR авторам и дробить функциональность на мелкие изменения объёмом до 300 строк, которые можно проверить за 5–10 минут.

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

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

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

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

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

В проекте Git предложено постепенное внедрение Rust в ядро системы, начиная с версии 3.0. Это тестовый шаг, аналогичный прошлым экспериментам с C99, чтобы дать сообществу время адаптироваться к новым требованиям инструментария. Первым кандидатом для перевода выбран модуль varint.c из-за его простоты и отсутствия зависимостей — уже реализованная версия на Rust прошла все тесты.

Пока поддержка Rust добавлена только в систему сборки Meson, с планами расширения на Makefiles. Также предстоит настроить CI-задачи для проверки сборки, форматирования кода и других аспектов. Это позволит поэтапно развивать инфраструктуру без немедленных обязательств, фокусируясь на процессе интеграции, а не на конкретных функциях.

• Предложение сделать Rust обязательной частью инфраструктуры сборки Git 3.0, пока как опциональная зависимость, с переходом на обязательную после появления поддержки в GCC.
• Высказаны опасения о снижении портируемости из-за ограниченной поддержки платформ Rust, сложности инструментария и повышении порога входа для новых разработчиков.
• Часть сообщества видит в этом ненужное усложнение для зрелого проекта и сомневается в целесообразности из-за малого объема нового кода.
• Другие считают, что Rust улучшит безопасность и консолидирует код, заменив существующие скриптовые языки, и что изучение нового языка — норма для разработчиков.
• Обсуждение включает технические детали о кросскомпиляции, поддержке различных архитектур и влиянии на такие проекты, как libgit2.

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

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

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

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/корпоративного использования нет аудита доступа и нормального способа перешифровки для новых сотрудников — приходится менять все пароли.

running-qix-malware
Репозиторий демонстрирует работу вируса QIX (1989) в эмуляторе DOS.

• Собранный DOS-бинарь запускается в браузере через эмулятор.
• Исходники на ассемблере и C, скрипты сборки.
• Инфицирует .COM-файлы, показывает бегущую линию.
• Безопасен: эмуляция изолирует вредоносный код.

• Участники вспомнили про инцидент Jia Tan и пожаловались, что npm до сих пор не автоматически блокирует публикации с обфусцированным кодом и шестнадцатеричными именами.
• Предложены меры: предпубликационный сканер с «задержкой на проверку», 2FA-апрув каждого релиза, опциональный «verified»-бейдж и поддержка Yubikey.
• Сомнения в пользе LavaMoat: не спасает от DLL в lifecycle-скриптах, не работает с Webpack HMR, а изоляция может быть дорогой.
• Обсуждали lock-файлы: хэши в package-lock защищают от перезаписи версии, но теги git всё ещё можно подменить; иммутабельность npm-тарболлов считается основной защитой.
• Namespaces (@scope) в npm есть с 2016 г., но «красивые» безскоповые имена всё ещё популярны, поэтому переход идёт медленно.

Форматирование кода должно быть лишним

В 80-х это уже знали.
Мой школьный учитель информатики, мистер Пейдж, участвовал в разработке компилятора Ada. Когда я в 2016-м жаловался на линтеры, он напомнил: проблему решили 40 лет назад. В Ada исходники не хранили — использовали IR-дерево DIANA. Каждый смотрел его в своём стиле: отступы, пробелы — всё равно.

Сейчас, в 2025-м, мы всё ещё спорим о запятых.

Как это работало
Рабочая станция Rational R1000 (1985) хранила не текст, а DIANA. IDE позволял редактировать дерево напрямую — проекционное редактирование. Компиляция была инкрементной, рефакторинг мгновенным, а «исходник» — просто красивой печатью дерева.

Плюсы: никаких holy-war’ов о табах, быстрая интеграция, встроенный VCS и отладка.
Минус: требовалась железная станция и знание Ada.

Вывод
Не нужно возвращаться к проекционным редакторам, но можно ли встроить идею «храним структуру, а не текст» в современные языки и IDE? Тогда форматирование станет личным вкусом, а не командным законом.

• Одни считают форматирование важным каналом коммуникации и показателем вкуса/опыта разработчика, другие — пустым байкшедом, который должен решаться автоматическим линтером без обсуждений.
• Хранение кода не как текста, а как IR/AST (пример — Ada/DIANA, Unison) позволяет каждому видеть свой вариант форматирования, но ломает привычные grep, diff, git и другие текстовые инструменты.
• Проекционное редактирование (JetBrains MPS, Chrome DevTools «pretty») демонстрирует «один IR — много представлений», но требует специальных IDE и пока не стало массовым.
• Проблема смешанных языков, legacy, необходимости универсального стандарта IR и инерции экосистемы тормозит переход от plain-text.
• Автоформатеры (gofmt, Prettier, Black) уже закрывают 90 % вопросов: на сохранении/коммите единый стиль, локально можно настроить git-фильтры smudge/clean.

Блог работает на переработанном Google Pixel 5

Вдохновившись постами в Mastodon о сайтах на ESP32 и Android-солнечных панелях, решил запустить блог с телефона. Успешно: вы это читаете.

Железо

• Google Pixel 5, от Verizon, без разблокировки загрузчика.
• Поддержка USB-OTG и Ethernet-адаптера.
• Питание: 100 Вт солнечная панель + Jackery 160 Вт — сайт полностью автономен.

Софт
Termux + Hugo из репозитория. Пакеты: git, screen, openssh, hugo, dufs (веб-загрузка файлов).
Сервисы: sshd, cronie через sv-enable.

Опыт
Первые сутки — разные версии Hugo и контроль заряда. Сейчас всё стабильно и быстро; внешне не отличить от VPS.

Планы: не трогать, пока не сломается.

• Автор запустил личный блог на старом Google Pixel 5, питая его от солнечной панели и аккумулятора, чтобы продемонстрировать энергоэффективность и повторное использование техники.
• Участники отмечают, что современные ARM-смартфоны потребляют <5 Вт против 50–100 Вт у x86-сервера, что экономит до 800 кВт·ч в год.
• Обсуждаются риски: старые аккумуляторы при 24/7 работе могут «раздуться» и вызвать пожар, поэтому предлагаются варианты безбатарейного питания по USB-PD.
• Вопросы безопасности: Pixel 5 уже не получает обновлений, а Termux-окружение может ломаться из-за несовместимости пакетов.
• Некоторые считают идею интересной, но для статического сайта дешевле и надёжнее использовать GitHub Pages или S3.

Magic Lantern 2025: Midsummer Edition
21 июня 2025

Возвращение официальных сборок

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

Что изменилось
После ухода a1ex в 2020 остались фрагментарные доки и нерабочая система сборки. Несколько волонтёров восстановили проект:

• обновили сайт и репозиторий;
• перешли на Git, современные ОС и инструменты;
• код стал чище, быстрее, компактнее;
• добавлена поддержка Digic 6/7.

Новая команда
g3gg0, kitor, names_are_hard, WalterSchulz.
Lead-dev: names_are_hard.

Новые камеры

• 200D / Kiss X9 / Rebel SL2
• 6D Mark II
• 750D / Rebel T6i / Kiss X8i
• 7D Mark II

Хотите помочь? Нужны разработчики C.

• Magic Lantern возвращается: это бесплатная надстройка, расширяющая возможности старых и новых Canon-ов за счёт реверса прошивки.
• Проект перешёл на Git, современный тулинг и чистую сборку без варнингов, что упрощает вход новым разработчикам.
• Нужен C и желание покопаться в «железе»; камеры стоимостью <$100 подходят, сообщество приглашает помогать.
• Пользователи вспоминают RAW-видео, таймлапсы, HDR-скрипты и другие «фичи», которых нет в штатной прошивке.
• Нет поддержки новых Sony/Nikon/Fujifilm, но многие мечтают о таких же проектах для других марок.

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) улучшает работу с системами контроля версий.

JavaScript отключён.
Включите его или перейдите в поддерживаемый браузер. Список браузеров — в Справке.

Что-то пошло не так.
Попробуйте ещё раз.

⚠️ Расширения, блокирующие трекинг, могут мешать работе сайта. Отключите их и обновите страницу.

• Участники считают, что давать LLM-агенту полный доступ к браузеру — это «смертельный трифекта»: чтение всех вкладок, кук и паролей.
• Основной риск — prompt-injection: любой сайт может внедрить команду, и агент выполнит её, потому что «каждое чтение — это запись в контекст».
• Люди сравнивают это с тем, что Microsoft делала скриншоты, но теперь молчат, когда AI получает plaintext-доступ к банковским данным.
• Единственный «безопасный» сценарий — код в git, где изменения легко откатить; всё остальное (покупки, банкинг, e-mail) считается безумным.
• Итог: без изоляции, sandbox и чёткого разграничения «что можно» агенты становятся идеальным вектором атак, а компании, их выпускающие, — объектом для судебных исков.

Код-ревью можно улучшить

Мы отложили эксперимент с git-review — инструментом, который делает ревью коммитом поверх PR.
Проблемы GitHub:

• состояние ревью не хранится в репозитории;
• всё через веб, с лагами и лишними кликами.

Локальный workflow
Я клонирую ветку, сбрасываю её, чтобы код выглядел «моим», и ревью в Magit: запускаю тесты, перехожу к определениям, помечаю файлы через git add -p.
Но оставлять замечания приходится в браузере: долго, неудобно, текстовое поле тормозит.

Идея git-review

• ревью = коммит с комментариями вида // CR(name): …;
• автор и ревьюер редактируют этот коммит (--force-with-lease);
• по окончании добавляется revert-коммит, сохраняя историю.

Почему не зашло
Комментарии в коде — супер, но:

• если меняешь код, комментарии смещаются и конфликтуют;
• --force-with-lease добавляет трения;
• нужен более мягкий merge для ревью, а не строгая цепочка хэшей.
  Довести до ума потребовало бы >500 строк «быстрого хака».

К тому же, в upstream-git может появиться Change-Id в стиле Gerrit, что изменит ландшафт.

• Основная боль: ревью приходит слишком поздно, заставляя переписывать всё с нуля.
• Решения: локальное ревью в IDE (IntelliJ, VS Code), stacked-PR, «reviewer merges»-подход.
• Инструменты: Gerrit, Phabricator, Graphite, GitButler, SourceHut, GitPatch, Tangled.
• Надёжный Change-ID в Git обещает фиксить проблемы с force-push и interdiff.
• Культура важнее инструментов: мелкие, самостоятельные коммиты, RFC-прототипы, совместное проектирование до кода.

Sequoia ведёт раунд $32 млн для Zed
Суммарное финансирование превысило $42 млн. Четыре года мы строили самый быстрый IDE, но это лишь фундамент. Следующая цель — живое, непрерывное сотрудничество, где разговоры о коде всегда связаны с актуальным состоянием проекта.

Проблема снимков
Git ограничивает обсуждение коммитами и ветками. Между коммитами разработчик работает изолированно; обсуждения в чатах быстро теряют связь с кодом. ИИ-агенты тем более страдают: каждый их шаг требует снимка, что тормозит итерации.

DeltaDB: версионирование операций
Мы создаём DeltaDB — систему, которая фиксирует каждое изменение на уровне операций через CRDT. Она совместима с Git, но позволяет:

• реальное время без снимков;
• пермалинки на символы, выживающие при любом рефакторинге;
• сохранение диалогов и контекста навсегда.

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

Zed и DeltaDB будут open-source с платными опциями. Набираем команду — присоединяйтесь.

• Вокруг Zed спор: продукт вызывает восторг качеством кода и скоростью, но $42 млн от Sequoia вызывают тревогу VC-«эншитификации».
• Главные сомнения: окупится ли такой капитал на «просто редакторе» и не приведёт ли к навязыванию AI-фич и сбора данных.
• Плюсы: финансирование даст ресурсы догнать Cursor/VS Code по AI и снизить трения миграции.
• Тех-фишка: анонс DeltaDB — версионирование уровня каждого символа через CRDT, совместимое с git.
• Часть пользователей уже ищет форки (Zedless) или возвращается к Sublime, опасаясь потери приватности и роста требований.

Основы 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 и улучшения обещаны в дорожной карте.

Большие файлы — давний враг Git: раздувают репозиторий, замедляют клонирование и дорого обходятся хостингам. С 2015 г. GitHub предлагает Git LFS, но он влечёт vendor-lock, плату за хранение, сложности отката и необходимость ставить расширение всем участникам.

Сегодня можно обойтись без LFS:

• Partial clone (--filter=blob:limit=100k) скачивает только нужные большие файлы, ускоряя клонирование в 30–50 раз и уменьшая дисковый след до размеров LFS-чекаутов.
• Недостаток: команды вроде git blame требуют до-загрузки, но для PNG-файлов это редко нужно.

Будущее — large object promisors:
Git-сервер будет прозрачно выгружать большие объекты в специальный remote, избавляя пользователей от LFS и хостинги — от лишних затрат.

• Критикуют Git LFS за «проприетарность», но многие отмечают, что протокол открыт и работает и с GitLab, и с S3.
• Основные боли: сломанные офлайн-режимы, многократная аутентификация, высокие расходы на трафик и неочевидные команды при клоне.
• Альтернативы — git-annex, DVC, Oxen, datamon и просто «не класть большие файлы в git», а хранить их в Artifactory.
• Часть участников ждёт нативную поддержку больших файлов в самом Git, чтобы не помнить про --filter=blob:none и LFS-указатели.

Modos Paper Monitor — открытый e-paper монитор 75 Гц и dev-kit.
Собрано $61 611 из $110 000, 37 дней до конца кампании.

В комплекте

• Плата на FPGA (Caster, 60 Гц, открытая прошивка).
• 6" и 13" монохромные панели; контроллер подходит и к другим экранам 6–13,3".
• HDMI/USB, Linux/macOS/Windows.
• Корпус-чертежи и ПО на GitHub.

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

• Закрытые драйверы и высокие цены тормозят e-paper.
• Мы даём инженерам и энтузиастам свободу экспериментировать и формировать стандарты (Discord, Mastodon, Matrix, Bluesky).

Возможности

• Низкая задержка: независимые области обновления, отмена прежних пикселей.
• Гибкие режимы: бинарный для скорости + гибридный серый для деталей.
• C API: полный контроль режимов и обновлений.

Цены

$199–$599, 6 вариантов комплектации.

GitHub-список совместимых экранов

• Проект Glider — полностью открытый: исходники, Verilog, документация и файлы платы на GitHub/GitLab.
• NLnet и ЕС профинансировали разработку; обсуждаются условия грантов и гражданство авторов.
• Контроллер на низкобюджетном FPGA выдаёт HDMI/USB-C, но пока не предлагает LVDS/eDP для моддинга ноутбуков.
• Демо показывает высокую скорость обновления при заметном «ghosting»; блики — особенность дешёвой панели, не самой платы.
• Участники хотят 21–24″ монохромный 30 Гц дисплей дешевле $500, сенсорный слой и драйверы X11/Wayland.
• Упомянуты альтернативы: Inkplate, TRMNL, Boox, а также DIY-кибердеки и ноутбуки ThinkPad T480 с e-ink.

Я архивирую Picocrypt · Issue #134 · Picocrypt/Picocrypt

===============

Пропустить к содержимому Меню навигации

Переключить навигацию

Войти

Настройки внешнего вида

• Продукт
  • GitHub Copilot Пишите код лучше с ИИ
  • GitHub Spark Новое Создавайте и внедряйте интеллектуальные приложения
  • GitHub Models Новое Управляйте и сравнивайте подсказки
  • GitHub Advanced Security Находите и исправляйте уязвимости
  • Actions Автоматизируйте любые процессы
  • Codespaces Мгновенные среды разработки
  • Issues Планируйте и отслеживайте работу
  • Code Review Управляйте изменениями кода
  • Discussions Сотрудничество вне кода
  • Code Search Ищите быстрее и точнее

Исследуйте

• Почему GitHub

• Все возможности

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

• GitHub Skills

• Блог

• Решения

По размеру компании

• Предприятия
• Малые и средние команды
• Стартапы
• НКО

По кейсам

• DevSecOps
• DevOps
• CI/CD
• Все кейсы

По отраслям

• Здравоохранение
• Финансовые услуги
• Производство
• Госструктуры
• Все отрасли

Все решения

• Ресурсы

Темы

• ИИ
• DevOps
• Безопасность
• Разработка ПО
• Все темы

Изучайте

• Обучающие маршруты

• События и вебинары

• Ebooks и whitepapers

• Истории клиентов

• Партнеры

• Executive Insights

• Open Source

  • GitHub Sponsors Поддержка разработчиков
  • The ReadME Project Материалы сообщества

Репозитории

• Темы

• В тренде

• Подборки

• Enterprise

  • Платформа для разработчиков на базе ИИ

Дополнения

• Advanced Security Корпоративная безопасность

• Copilot for business Корпоративные ИИ-возможности

• Премиум-поддержка 24/7

• Цены

Поиск или переход...

Поиск кода, репозиториев, пользователей, issues, pull requests...

Поиск

Очистить

Советы по синтаксису

Оставить отзыв

Мы читаем каждый отзыв и относимся к нему серьезно.

• [x] Указать мой email для связи

Отмена Отправить отзыв

Сохраненные поиски

Используйте сохраненные запросы для быстрого фильтра

Название

Запрос

Все квалификаторы в документации.

Отмена Создать сохраненный поиск

Войти

Зарегистрироваться

Настройки внешнего вида

Сброс фокуса

Вы вошли в другой вкладке. Перезагрузите страницу, чтобы обновить сессию. Вы вышли в другой вкладке. Перезагрузите страницу. Вы переключили аккаунты. Перезагрузите страницу. Закрыть уведомление

{{ message }}

Picocrypt/Picocrypt Публичный

• Уведомления

• Обсуждение вокруг автора проекта Picocrypt, который архивирует репозиторий и уходит из разработки из-за разочарования в «вибе-кодинге» и доминировании ИИ/LLM, оформлено как диалог с Gemini, что некоторых сбило с толку.
• Часть комментаторов сочувствует утрате «ремесленного» подхода и демотивации, другие считают реакцию чрезмерной, доomer-ной или попыткой личного брендинга.
• Спор о лицензиях: MIT критикуют как «слабую» (корпорации выигрывают), предлагают AGPL/SSPL и обсуждают бессмысленность запрета «обучения ИИ» из-за непроверяемости корпусов.
• Поднимаются вопросы ответственности перед донорами на аудит и ожиданий сообщества: код доступен, но без поддержки возникают риски багов/совместимости.
• Есть технические замечания к проекту (напр., зависимость от OpenGL на macOS, результаты VirusTotal) и альтернативы (7zip, VeraCrypt); некоторые форкают и планируют упростить GUI.
• Мнения о LLM: от полного отказа и счастья без них до признания их неизбежности как «массового производства кода»; отмечают, что ИИ не делает людей экспертами, и традиционные инструменты часто надежнее.
• Отмечают парадокс: критикуя ИИ-кодинг, автор собирается в исследование LLM; часть видит в этом стратегию карьеры и нехватку ресурсов на опенсорс, а не «конец качества».