Hacker News Digest

Byte Buddy — библиотека для генерации Java-классов во время выполнения без компилятора. В отличие от встроенных средств, она позволяет создавать произвольные классы, а не только прокси по интерфейсам.

---

Поддержка

• Коммерческая: обучение, консультации, разработка — пишите rafael.wth@gmail.com.
• Общие вопросы: задавайте на Stack Overflow с тегом byte-buddy; для неформатных тем — рассылка.
• Баги и фичи: issue tracker; пришлите пример кода и версию Java.
• Разработка: делайте pull-request; крупные фичи обсудите заранее в рассылке.

Проект ведёт Rafael Winterhalter с 2014 г.

• В обсуждении сравнивают новый стандартный API для генерации байт-кода в JDK 24 (JEP 484) и старое решение ByteBuddy.
• Упоминают JavaPoet (теперь форк от Palantir) как удобный инструмент для генерации кода на уровне исходников.
• Micronaut показан примером фреймворка, избегающего runtime-генерации, делая всё во время компиляции.
• Поднимаются вечные споры «Java vs Kotlin»: кто-то считает Java «C для JVM», кто-то предпочитает Kotlin, а LLM якобы лучше понимают Java.

Open SWE — первый open-source агент для асинхронной разработки в облаке.
Подключается к вашим репозиториям GitHub, берёт задачи из issue и самостоятельно исследует код, пишет, тестирует, исправляет ошибки и открывает pull-request.

Как попробовать

1. Перейдите на swe.langchain.com.
2. Авторизуйтесь в GitHub и выберите репозитории.
3. Добавьте ключ Anthropic в настройках.
4. Создайте задачу и наблюдайте.

Особенности

• Человек в цикле: агент показывает план, вы можете править, удалять или дополнять его без перезапуска.
• Обратная связь на ходу: во время выполнения можно отправить новое сообщение — агент учтёт его без сбоя.
• GitHub-нативность: задача = issue, результат = PR. Достаточно добавить метку open-swe-auto, чтобы агент начал работу.
• Безопасность: каждая задача запускается в изолированном контейнере Daytona.
• Облако: параллельные задачи, никакой нагрузки на ваш ПК.
• Планирование и ревью: отдельные агенты Planner и Reviewer минимизируют поломки CI.

• Часть сообщества мечтает о полностью локальных, прозрачных агентах без облачных «чёрных ящиков» и навязанных UI.
• Другие уверены, что будущее за долгоживущими, асинхронными, облачными агентами, которые уже почти умещаются в памяти пары вкладок Chrome.
• Утилита вызывает подозрения: AGPL-код Daytona не раскрывает control-plane, а README сразу предлагает регистрацию в сервисе.
• Пользователи жалуются на невосстановимые ошибки и просят переноса контекста между сессиями.
• Скептики напоминают: VRAM всё ещё редкость, а «облачная» модель потребления данных не способствует технологической независимости.

Как военный проект стал щитом приватности

На скрипучем поезде в тумане я пытаюсь зайти на сайт, но Wi-Fi блокирует его. Запускаю Tor Browser — страница открывается мгновенно.

Tor, или «тёмная сеть», ассоциируется с криминалом, но финансируется частично правительством США, а BBC и Facebook ведут в нём «зеркала» для обхода цензуры. Суть: трафик шифруется и прыгает по серверам мира, скрывая пользователя и обходя блокировки.

От криптовойн до Tor

90-е: хакеры-циферпанки вооружают гражданских военным шифрованием, предупреждая, что интернет может стать тоталитарным. Бизнес и Пентагон поддерживают: свободный поток данных = рыночная победа.

В исследовательской лаборатории ВМС США (NRL) инженеры ищут способ скрыть IP подлодок. Их решение — луковая маршрутизация — ложится в основу Tor.

Двойная игра государства

Сегодня одни ведомства финансируют Tor, другие требуют «задних дверей». Технологии, рождённые для шпионажа, стали инструментом сопротивления цензуре и массовой слежке.

• @neilv использовал Tor для скрытого мониторинга международной торговой площадки, выбирая выходные узлы под нужные регионы.
• @palsecam и @jmclnx рассказали, что запускать ретранслятор или bridge дёшево (VPS за $5) и безопасно, помогая обходить цензуру.
• Некоторые считают Tor «мертвым» или скомпрометированным; другие советуют прятаться в толпе, использовать VPN, residential-прокси или переходить на i2p.
• Книга «Tor: From the Dark Web to Your Browser» доступна бесплатно от MIT Press и получила положительные отзывы.
• Основные советы по безопасности: брать Tails на флешке, не ставить расширений в Tor Browser, не логиниться личными данными.

Задача: перенести TypeScript-утилиту Ruler на Rust, проверить идентичность через bash-тест.
Модели: GPT-5 (новый, превью) и Claude 4 Sonnet.

GPT-5

• Сразу прочитал код, составил подробный plan.md, получил одобрение.
• Работал почти без остановок, дважды отчитывался о статусе.
• Сначала написал bash-скрипт, который запускает оригинал и порт во временной папке и сравнивает вывод.
• Затем сгенерировал структуру src/, Cargo.toml, CLI-аргументы, логику apply/init/revert, обработку конфигов и MCP.
• Итеративно правил код, пока тест не прошёл «зелёным».
• Время: ~20 мин, 1 коммит, ветка feat/rust-port.

Claude 4 Sonnet

• Та же инструкция.
• Сразу начал писать Rust, но упустил bash-тест; пришлось напомнить.
• Тест написал быстрее, но менее читаемый.
• Порт делал «пачками»: сначала CLI, потом логика, потом MCP.
• После 3-х итераций тест прошёл.
• Время: ~30 мин, 3 коммита.

Вывод

• GPT-5 агентнее: сам планирует, реже спрашивает, меньше ошибок.
• Claude надёжнее в деталях, но требует чётких шагов.
• Оба справились, но GPT-5 ощущается «ближе к одной команде — один результат».

• Пользователи сомневаются в объективности сравнений: результаты сильно зависят от системных промптов, харнесов и задач.
• Критика выбора моделей: вместо топ-версии Claude Opus сравнивали более дешёвый Sonnet, что искажает оценку «лучшей» модели.
• Стоимость vs качество: большинство разработчиков не готовы платить 10× за Opus, поэтому GPT-5 рассматривают как «cost-effective» вариант.
• Опыт в продакшене: многие находят Claude Code (Sonnet/Opus) надёжнее при работе с большими кодовыми базами и TDD, тогда как GPT-5 хорош для разовых скриптов.
• Нет единой метрики: из-за недетерминированности моделей и субъективных критериев «хорошего кода» каждый получает разные результаты.

Хвостовая рекурсия превращает рекурсию в цикл: компилятор заменяет вызов на безусловный jmp, поэтому стек не растёт.

Обычная рекурсия кладёт промежуточные значения в стек, тратит O(n) памяти и вытесняет кэш.
Цикл же держит результат в аккумуляторе, использует O(1) памяти и линейное время.

Ключевое правило хвостовой рекурсии:
вызов должен быть последним выражением функции. Тогда компилятор может выбросить текущий фрейм и передать управление напрямую.

Пример суммы списка

Обычная версия:

(define (sum l)
  (if (empty? l) 0
      (+ (first l) (sum (rest l)))))

Хвостовая версия:

(define (sum l acc)
  (if (empty? l) acc
      (sum (rest l) (+ acc (first l)))))

Аргументы l и acc перезаписываются «на месте», как переменные цикла.

Упражнение 1 — счётчик чётных/нечётных:

(define (even-odd l [e 0] [o 0])
  (if (empty? l) (cons e o)
      (let ([x (first l)])
        (if (even? x)
            (even-odd (rest l) (add1 e) o)
            (even-odd (rest l) e (add1 o))))))

Упражнение 2 — сглаживание дерева:
используйте аккумулятор-список и обход в обратном порядке, чтобы сохранить хвостовой вызов.

• Теоретически хвостовая рекурсия и циклы эквивалентны: любую хвостовую рекурсию можно превратить в цикл (и наоборот), но взаимно-рекурсивные функции требуют дополнительной работы.
• На практике циклы чаще проще для чтения и не ломают стек, тогда как хвостовая рекурсия нуждается в оптимизации (TCO), которую не все языки поддерживают (Python, V8 её нет).
• Некоторые языки (Scala, Clojure, F#) дают компромиссные конструкции (@tailrec, recur), сохраняющие функциональный стиль и гарантирующие отсутствие переполнения стека.
• Вместо явной хвостовой рекурсии часто достаточно высокоуровневых комбинаторов вроде fold/map, но они не всегда позволяют досрочный выход и могут расходовать O(N) памяти.
• Участники сходятся во мнении: владеть обоими подходами полезно, выбор зависит от языка, задачи и привычек команды.

Разработчики всё чаще пишут документацию в специальных «контекст-папках», чтобы ИИ мог самостоятельно и точно решать задачи. Это docs-driven development: кодят меньше, пишут больше, потому что ИИ теперь обязан «RTFM».

Качество ответа LLM прямо зависит от качества входных данных. Чем больше контекстное окно, тем больше релевантной информации можно подать. Поэтому инженеры учатся писать структурированные инструкции и создавать целые библиотеки контекста.

Контент-куратор — это технический писатель, который строит стратегию знаний и для людей, и для ИИ. Контекст важнее «контента»: он ограничен, релевантен и придаёт смысл. Писатели должны владеть процессами AI-документации, включая подготовку контекста (docs-as-data).

Четыре года назад я утверждал, что писатели влияют на дизайн API словами. Теперь это распространилось на всю разработку: мы можем «вызывать» программы текстом. Большинство команд уже отдают llms.txt и Markdown для ИИ, но следующий шаг — упаковывать контекст в удобные для LLM форматы (возможно, на базе DITA). Цель — сделать знания доступными и человеку, и машине.

• AI заставляет писать больше документации — скучно, но полезно и исключает оправдания прокрастинации.
• LLM плохо справляются с новыми/обновлёнными API, часто предлагают устаревший код, если явно не указать «смотри свежие доки».
• Чтобы LLM был полезен, нужно самому понимать задачу и давать точный контекст; иначе результат неточен.
• Некоторые компании уже отдают приоритет AI-читабельным форматам (llms.txt, claude.md), но это пока редкость, а не норма.
• Хорошая документация полезна людям вне зависимости от ИИ; если ИИ подталкивает улучшать её, это плюс.

Современные ИИ-чаты умеют отвечать на сложные вопросы, потому что мы так и не научились структурировать информацию. Пример: «Какое животное изображено на флаге страны, где первая британская колония появилась в год, когда Швеция объявила войну Франции?» — ChatGPT за секунды выдал «попугай сиссеро на флаге Доминики, колония 1805 г.», а Google AI-виджет провалился.

Такой «поисковый» паттерн повсюду: Google Drive — облачная папка, которую легче искать, чем упорядочивать; сайты вместо структуры набиты ключевыми словами; документацию заменяют чат-боты.

Семантический веб, где данные должны были быть машиночитаемыми и связанными, так и не случился: вместо структурированного HTML — динамические div-ы без метаданных. Личные компьютеры не стали персональными базами знаний с семантическими связями, как мечтал ХайперКард.

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

• Участники сравнивают идею «всё структурировать» с утопией «если бы все просто были хорошими людьми» – красивая теория, но нереалистична.
• Напоминают, что Semantic Web, Knowledge Graph и Cyc пытались кодировать знания вручную, но масштабировались плохо: люди не умеют быстро и точно описывать мир.
• Отмечают, что современные ИИ-модели стали «пластырем», который сам строит семантические связи из хаотичных данных, хотя и с ошибками.
• Подчёркивают: поисковики и LLM дополняют друг друга; ни один не решает всё, но вместе дают результат.
• Главный вывод: неудача не в «плохих людях», а в сложности мира и в том, что рутинная работа по разметке никому не принадлежит и никем не финансируется.

AGI стремится к универсальности, но нельзя просто import everything. Решение — компрессия и обобщение: небольшая модель покрывает огромное пространство задач. Глубокое обучение сжимает терабайты данных в десятки гигабайтов весов, и LLM не только имитируют текст, но и умеют, например, играть в шахматы без явного обучения.

Следующий шаг — world-models, способные представлять не только текст и картинки, но и всю окружающую реальность. Такая модель могла бы «смоделировать Тибет» и сообщить погоду, а робот — планировать движения, опираясь на внутреннюю симуляцию мира. Проблема в колоссальном объёме видеоданных и вычислений, поэтому мало кто рискует.

Google DeepMind рискнул: три дня назад представил Genie 3 (Generative Interactive Environments). Если GPT создаёт текст, Veo и Sora — видео, то Genie превращает описание в интерактивную видеоигру, где можно бродить минутами. Пока коротко, но это качественный скачок и намёк на будущее, где модели будут поддерживать длинную когерентность не только в тексте, но и в «живых» мирах.

• Пользователи высмеяли идею «стимулировать Тибет» вместо обычного запроса погоды.
• Рынки ставок и графики вызвали споры: одни видят рост ожиданий Gemini-3, другие указывают, что Gemini 2.5 уже выше GPT-5 в бенчмарке.
• Многие считают статью пустой и отказываются верить демо, пока Genie 3 не станет публично доступен.
• Обсуждение свелось к тому, что ни GPT-5, ни Gemini пока не близки к AGI, а термин «AGI» постоянно меняется под маркетинг.

Сокращённый перевод на русский

Короткий список конкурса «Астрономический фотограф года 2025» (ZWO) уже опубликован. На сайте Royal Museums Greenwich представлены отобранные работы, но полный список фотографий и авторов в предоставленном фрагменте не указан.

• Участники восторгаются красотой снимков, но обсуждают, насколько они «настоящие».
• Норвежец и другие отмечают, что северное сияние и другие объекты на фото выглядят ярче, чем вживую из-за длинной выдержки, HDR и прочей обработки.
• Спорят о композитах: кто-то считает их обманом, кто-то — способом показать невидимое глазу.
• Подозревают AI-генерацию, но организаторы требуют RAW-файлы и описание обработки, чтобы проверить подлинность.
• Уточняют, что «солнечные вспышки» снимают через H-alpha-фильтр, а геометричные постройки на одном кадре — реальные скульптуры в Китае.

• Чёткое ТЗ — пишу заранее, чтобы агент видел контекст.
• Файл-инструкция по запуску линтервов и сборки.
• Саморевью — прошу Claude проверить свой код.
• Глобальный гайд ~/.claude/CLAUDE.md с правилами: мелкие шаги, TDD, простые решения, максимум 3 попытки при ошибке.

Качество
Я вручную читаю и тестирую всё, что выходит из LLM; отвечаю за PR независимо от автора кода.

• Ключ к успеху — писать подробные спецификации: кто-то тратит 2 часа на 12-шаговый документ и получает отличный результат, другие же считают, что даже «чистые» спеки не спасают от схода с курса и бесконечных правок.
• Мнения о CLAUDE.md разделились: одни держат файл коротким (<100 строк) и минималистичным, другие вообще не видят в нём пользы из-за «context rot» и субъективных инструкций.
• Работа с большими старыми кодовыми базами по-прежнему сложна: большинство признаёт, что Claude Code лучше справляется с новыми pet-project’ами, чем с «грязными» legacy-фичами.
• Популярные тактики: шаг-за-шагом микро-PR, TDD-агент, запуск puppeteer-тестов для «замыкания цикла», code-review собственных патчей самим агентом.
• Некоторые вообще отказались от спецификаций: инкрементально подсказывают «следующий шаг, какой сделал бы я», сразу коммитят дифф и правят на лету.