Hacker News Digest

• Увлечение — восстановление данных с кассет QIC-80 90-х гг.
• Драйвер ftape (Linux 2.4) последний раз собирался ~2000 г.; с тех пор приходится держать CentOS 3.5.
• Привод подключается к контроллеру гибкого диска: дёшево, но 500 Кбит/с и куча «магии» портов/IRQ.
• Под DOS/Windows есть проприетарные утилиты, но только ftape даёт «сырой» дамп, независимо от формата ПО, которое писало кассету.

Цель: переписать драйвер под современное ядро без боли.
Инструмент — Claude Code (Claude 3.5 Sonnet) в режиме «актов» (акт = автоматический цикл «предложи-отладь-протестируй»).

Ход работы

1. Запустил claude в каталоге исходников ftape-4.04 (1999 г.).
2. Первый акт: «сделай модуль для ядра 6.10». Claude выдал:
   • заменил cli/sti на spinlock_t;
   • sleep_on → wait_event;
   • register_blkdev → blk_mq;
   • kmalloc → kmalloc_array;
   • добавил MODULE_LICENSE/AUTHOR/DESCRIPTION.
     Собралось с десятком предупреждений.
3. Акт 2: «убери варнинги». Убрал устаревшие ioctl, обернул printk в pr_*, добавил fallthrough;.
4. Акт 3: «проверь на x86_64». Исправил long ↔ int в структурах, выровнял u8/u16 через __packed.
5. Акт 4: «протестируй на железе». Создал QEMU-образ с контроллером FDC, подключил образ кассеты.
   • первый insmod — kernel oops; Claude добавил BUG_ON(!request_region) и проверку IRQ.
   • второй — ftape видит привод, но «unknown format»; Claude вставил распознавание QIC-80 по ID_CRC.
   • третий — успешный дамп 120 Мб за 40 мин.
6. Акт 5: «очисти и оформи». Удалил весь #ifdef LINUX_2_0, добавил README.md, Kconfig, Makefile для in-tree сборки.

Результат

• 2 500 строк C → 1 100; 45 файлов → 12; минус 4 архаичных под-драйвера.
• Собирается как out-of-tree (6.6–6.12) и как in-tree (патч 30 Кб).
• Скорость 470 Кбит/с — предел FDC, но стабильно.
• Поддержаны только QIC-80; QIC-40/3010/3020 выкинуты (никто не просил).

Вывод
Claude Code способен переварить древний драйвер за вечер: сам генерит патчи, тестирует в QEMU и оставляет человеку только катать ленту.

• Claude Code и другие LLM-инструменты превращаются в «силовой множитель» для разработчиков: ускоряют работу в знакомых фреймворках и позволяют быстро осваивать новые.
• Главное — самому понимать, что делаешь: чёткие промты, ключевые слова предметной области и умение сверять результат критически снижают количество багов.
• Примеры успеха: порт драйвера ftape с Linux 2.4 на 6.8, апгрейд Pydantic V1→V2, inline-ASM под Apple, модернизация 15-летнего PHP-кода — всё за часы вместо недель.
• Самые ценные фичи: долгие процессы в терминале, автоматическая проверка своего кода, быстрое написание тестов и бенчмарков «на заказ».
• Безопасность: при работе с sudo-операциями или ядром итерации лучше вести вручную, чтобы LLM не сломала систему.

GLM-4.5

• 355B параметров, 32B активных; 128K контекст; 96K выход
• MoE-архитектура, 15T токенов дообучения, RL-доработка
• Режимы: thinking (сложные задачи) и мгновенный ответ
• Инструменты, JSON, потоковый вывод, кэш контекста

GLM-4.5-Air

• 106B/12B, дешевле и быстрее, качество почти на уровне GLM-4.5

GLM-4.5-X / AirX / Flash

• X: максимум скорости и качества
• AirX: лёгкий + сверхбыстрый
• Flash: бесплатный, для кода и агентов

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

• Пользователи тестируют китайскую модель GLM 4.5 и GLM 4.5 Air от Z.ai как дешёвую замену Claude Sonnet в Claude Code и RooCode.
• Модель показывает хорошие результаты в коротких задачах, но уступает по длине контекста и стабильности.
• Подозрения, что OpenRouter и другие поставщики могут отдавать квантованные версии, что портит качество.
• Политика приватности Z.ai разрешает вечное использование отправленного кода и промптов — кто-то напуган, кто-то считает это нормой.
• Документация и интеграция вызывают нарекания: нет чёткой инструкции для Claude Code, приходится использовать прокси-обёртки.

В точку!
Claude Code сегодня молчит.
Код • сделал @yoavf

• Участники высмеивают, что Claude и другие LLM постоянно повторяют «You're absolutely right!», воспринимая это как навязчивое поддакивание.
• Многие считают такую слащавость раздражающей и даже вредной: модель соглашается, даже когда пользователь явно ошибается, вместо того чтобы спорить.
• Некоторые видят в этом маркетинговую проблему Anthropic: бренд рискует стать синонимом «облизывающего» бота, а не полезного помощника.
• Пользователи делятся лайфхаками («говори сначала неправильный ответ», «добавь в промпт запрет на лесть»), но признают, что полностью убрать поддакивание пока не получается.
• Самый популярный компромисс: смириться с фан-клубом, потому что «лучше пусть ошибается и вежлив, чем уверенно неправ и упрям».

Что это
Приложение для macOS, которое автоматически сохраняет «точки восстановления» проектов Claude Code. Если что-то пошло не так — один клик и вы вернулись к рабочей версии.

Как работает

1. Выберите папку проекта.
2. Продолжайте кодить — изменения отслеживаются сами.
3. При завершении задачи создаётся контрольная точка.
4. В любой момент можно откатиться или посмотреть diff.

Основное

• Авто-обнаружение изменений — без настройки.
• Визуальный diff — видно, что добавлено, удалено, изменено.
• Полное резервное копирование — каждая точка = весь проект.
• MCP-интеграция — Claude Desktop сам создаёт точки при task completed.
• macOS 13.5+, бесплатно.

Команды MCP

update_task_status("task", "completed")  # контрольная точка
restore_checkpoint("id")                 # откат

Скачать
Mac App Store

• Пользователи спорят, нужен ли отдельный инструмент для «чекпойнтов» в Claude Code: одни советуют Jujutsu или обычный git, другие хотят встроенную функцию «откатить и код, и контекст».
• Разработчик подтверждает, что под капотом используется git в скрытой папке .claudecheckpoints, чтобы не пачкать основной репозиторий.
• Некоторые считают задачу надуманной: достаточно добавить в CLAUDE.md правило «делай git-commit после каждого изменения» или пользоваться Cursor/Aider.
• Критика UI и стабильности: зависания, лишние кнопки, «vibe-coded» дизайн.
• Общий вывод: пока Claude Code не добавит родные чекпойнты, такие сторонние обёртки имеют смысл, но рискуют стать ненужными после одного обновления самого Claude.

async-server — это CLI-утилита, объединяющая Claude Code, Linear и GitHub PR.
Она позволяет:

• Планировать задачи прямо в терминале (как в Linear).
• Писать код с помощью Claude Code: создавать ветки, коммиты, PR.
• Ревьюить изменения и мержить без выхода из консоли.

Установка:

npm i -g async-server
async-server init

Команды:

• async task "добавить логин" – новая задача.
• async code – Claude генерирует код.
• async pr – создаёт PR и связывает с задачей.

Полностью асинхронный workflow: задачи, код, ревью — всё в одном потоке.

• Пользователи хвалят темную тему и концепцию, но сомневаются в необходимости платить GCP за каждое взаимодействие и просят локальный режим.
• Критика: не хватает полноценного тестирования (сборка/запуск кода), а упоминание Linear в заголовке кажется лишним.
• Автор подтверждает: сейчас большая часть выполняется в облаке, но команда работает над локальной версией и улучшенным тестированием изменений.

Я начал с примитивного подхода: описывал задачу, ждал результат, указывал на ошибки. Для простых вещей сойдёт, но при росте сложности появились проблемы:

• беседа становится единственным источником истины;
• старые инструкции могут быть затёрты новыми;
• контекст ограничен, и старые детали «забываются».

Решение — план-документ. Первым шагом прошу Claude Code записать план в файл, например @plans/query-builder.md. В запросе даю описание фичи, указываю примеры из других планов, но не навязываю детали реализации. Ожидаю:

• переформулировку требований;
• черновой код или псевдокод;
• команды для проверки качества (типы, линтер, тесты).

Если план не устраивает, объясняю, что не так, и Claude переписывает. Иногда возвращаемся к первому варианту — быстрее, чем писать код и потом переделывать.

Важный шаг: делаю план «живым». Прошу обновлять его во время работы, особенно после коммитов, когда линтер или тесты показывают ошибки. Это решает проблему контекста: можно очистить чат и продолжить с одним лишь актуальным планом.

Проверь, что план в @plans/query-builder.md актуален, и закоммить изменения.

В процессе периодически просматриваю изменения; финальный код легче понять, если рядом лежит обновлённый план.

• Участники делятся опытом «один-шот» разработки: предварительно создают подробный план в нескольких .md-файлах (архитектура, модели, тесты) и только потом запускают Claude Code.
• Ключевая идея — чёткая фиксация требований и контекста позволяет ИИ реализовать фичу без постоянных «подталкиваний», повышая качество и снижая затраты времени.
• Многие сравнивают такой подход с TDD или waterfall: сначала проектирование, потом кодирование; это заставляет лучше продумывать систему.
• Поднимаются вопросы цены: Claude Code дороже Cursor/OpenAI, поэтому для сайд-проектов приходится ограничивать токены или использовать более дешёвые планы.
• Некоторые комбинируют инструменты: пишут план в Gemini/OpenAI, а реализацию доверяют Claude Code, чтобы получить «+15-20 %» к качеству.

• Контекст = память агента
  Добавляйте только релевантные файлы. Помещайте их в context/ и docs/, укажите агенту читать README.md этих папок и самостоятельно выбирать нужные.
  Пример вставки в промпт:

  - При старте выведи список файлов в context/ и docs/
  - Прочитай README.md каждой папки
  - Используй только нужные
  

  Экономит токены и деньги.

• Контекст «на месте»
  Если агент постоянно ошибается (например, пишет тесты на Jest вместо Vitest), вставьте напоминание прямо в файл:

  // Проект использует vitest и cypress
  // Не использовать Jasmine/Jest
  // Запуск: pnpm test
  

• Модель и агент
  Для сложных задач берите Claude Sonnet. Пробуйте Claude Code и Roo Code — они сами подтягивают файлы проекта.
  Активные пользователи → оплата по факту; редкие → бесплатные чат-боты.

• Не «кодинг», а «создание»
  Пишите документацию в context/ (для разработки) и docs/ (для пользователей) и заставляйте агента обновлять их после каждого значимого изменения.

• Итог
  Это не единственный путь к успеху, а лишь то, что помогло мне — любителю — довести проект до рабочего состояния.

• LLM-агенты склонны к избыточной абстракции и «улучшениям» — нужно явно ограничивать их свободу.
• Помогает задавать агенту до 10 уточняющих вопросов, чтобы сузить контекст и избежать ошибок.
• Для тяжёлых пользователей дешевле подписка Claude Code, чем оплата за токены по API.
• Агенты могут отключать тесты вместо их починки — поведение зависит от языка и фреймворка.
• Контекст лучше держать прямо в тестах или использовать под-агентов и файлы AGENTS.md.
• Краткие, точные промпты (в стиле RFC) часто работают лучше длинных и «разговорных».

Два месяца писал код только с Claude Code. Поначалу — восторг: задачи летят, коммиты сыплются.
Сейчас, когда приложение разрослось, всё затормозилось. Парадокс: само приложение умеет запускать множество копий Claude Code, и я держу одновременно 5 инстансов, пока придумываю новые фичи.

Задержка появляется при проверке PR. Каждый приходится локально применять, читать логи, просить Claude чинить собственные ошибки.
Объём кода огромен, но скорость воспринимается как мучительно медленная: после первого «ускорения» хочется, чтобы всё так же летело. Это затягивает.

Пока Claude остаётся QA-инженером, который требует контроля. Не верю, что CLAUDE.md решит проблему: правил-то он едва придерживается, а уж комплексные интеграционные тесты — тем более.

Пока что продолжаю мёржить PR вручную, вешать git-хуки за качество и «мчаться» по задачам, пока не выяснится, что модель придумала несуществующие методы библиотеки, и придётся вырезать Clerk и писать GitHub OAuth с нуля.

• Участники обсуждают «проблему золушки»: задача должна быть достаточно большой, чтобы оправдать описание и ревью, но не настолько, чтобы LLM «утонула».
• Ключевой узкое место — человек: быстро генерируемый AI-код всё равно требует внимательного прочтения и понимания.
• Нужно сразу задавать архитектуру и контролировать её, иначе проект быстро разрастается хаотично; README и тесты помогают, но сами тесты иногда «ломаются» или игнорируются агентом.
• Эффективные подходы: дробление задач на 4-5 мелких, запуск нескольких специализированных агентов (док-мен, безопасность, оптимизация), строгая типизация и CI-хуки для поимки галлюцинаций библиотек.
• Некоторые считают, что LLM-программирование — это отдельная дисциплина, где привычные паттерны не работают, а «медленно и гладко» оказывается быстрее в итоге.

• Пользователи жалуются: код от «больших» LLM выглядит красиво, но полон галлюцинаций, особенно в редких/NDA-сферах.
• Embedder позиционируется как узкоспециализированный агент для embedded: ищет по даташитам, запускает стат-анализ, отладку GDB, работает офлайн (FDE/BYOK) для корпоративных клиентов.
• Основной способ борьбы с ошибками — «строгое грундование» через цитаты из документации и планирование, а не дообучение (пока обёртка над frontier-моделями).
• Поддержка ESP32 уже есть (можно загрузить доки вручную, готовится официальная интеграция с Espressif).
• Планы: MCP-сервер для Claude Code, локальное самостоятельное хранение кода, возможные узкие fine-tune-модели под топ-20 вендоров.

• Участники не могут предсказать, как будет выглядеть индустрия через три года: все модели развиваются слишком быстро.
• Одни считают Cursor просто «обёрткой» над Claude, другие подчеркивают его уникальные фичи (визуальный интерфейс, история, автодополнение).
• Статистика показывает, что Claude Code обгоняет Cursor по популярности, но Cursor всё ещё опережает в автодополнении кода.
• Многие сомневаются в устойчивой прибыли Cursor из-за «всё-включено» модели и высоких токен-расходов.
• Обсуждается, что «обёртка» может стать «настоящей компанией», если создаст собственные технологии и моаты.

LLM-разработка: краткий итог

• Мифы: LLM не делают код продакшн-готовым, требуют понимания задачи и хорошо структурированных кодовых баз. Использование LLM снижает навыки чтения документации и глубокого мышления.
• Агенты — это просто цикл «LLM → вызов локального API → ответ → LLM снова». Инструменты: навигация, редактирование, shell, поиск, MCP-серверы.
• Проблемы продуктов
  • Нестабильность: модели и цены меняются еженедельно.
  • Нет детерминизма, приходится постоянно обновлять промпты и MCP.
• Тесты
  • Python, TypeScript, Rust, Flutter, сложные рефакторинги — справляются.
  • Не справились: Token Field во Flutter (редкий компонент, сложное управление состоянием). Claude Opus 4.1 и GPT-5 провалили задачу.

Продукты

• GitHub Copilot

  • Плюсы: быстрое автодополнение, стабильность, низкая цена.
  • Минусы: слабые «агенты», нет контекста всего проекта.

• Claude Code Pro

  • Плюсы: лучший «умный» режим, хорошо работает в больших кодовых базах.
  • Минусы: дорого, медленно, иногда «теряется».

• Gemini CLI / Jules

  • Плюсы: бесплатный CLI, быстрый.
  • Минусы: слабые модели, ограниченные возможности.

• Kiro, Cursor, Windsurf

  • Плюсы: встроенные редакторы, удобные интерфейсы.
  • Минусы: дороже, часто баги, привязка к конкретному редактору.

Когда LLM полезны

• Лучшие языки: Python, TypeScript/JavaScript, Go.
• Лучшие задачи:
  • Репетитивный код, тесты, миграции.
  • Документация, примеры, объяснение legacy.
• Плохо:
  • Редкие фреймворки, сложные UI, архитектурные решения.
  • Надёжность и безопасность.

Вывод
LLM — полезный инструмент для рутины и прототипов, но не заменяет мышление и глубокое понимание.

• Многие спорят с тезисом «использовать LLM в коде тривиально»: на практике нужны месяцы, чтобы понять, что делегировать, как формировать промпты и управлять контекстом.
• Кто-то сравнивает LLM с «однорукими бандитами»: результат часто случаен, а «навыки» сводятся к удаче и базовому гуглению.
• Другие делятся успешным опытом: при жёсткой архитектуре, тестах и узких промптах Claude Code и аналоги дают 9/10 полезных патчей.
• Утверждение, что LLM «заставляют» выбирать мейнстек, опровергают разработчики на Clojure, D и других нишевых языках.
• Общий вывод: LLM — мощный инструмент, но требует экспериментов, критического ревью и понимания своих ограничений; без этого он быстро превращается в источник технического долга.

• Introducing GPT-5 — YouTube

• Пропустить навигацию

• Поиск / Поиск голосом

• Войти

• Смотреть позже • Поделиться • Копировать ссылку • Покупки

• Нажмите, чтобы включить звук • 2x

• Если воспроизведение не началось, перезапустите устройство.

• Вы вышли из аккаунта. Просмотры могут влиять на рекомендации на ТВ. Чтобы избежать этого, отмените и войдите на YouTube на компьютере.

• Отмена • Подтвердить

• 37:35 • 7 августа, 10:00 GMT-7

• Далее • Прямой эфир запланирован • Играть

Introducing GPT-5

• OpenAI • Подтверждено • 1,65 млн подписчиков
• Подписаться • Подписаны
• 6 522 ожидают • Запланировано на 7 авг. 2025
• 1K • Поделиться • Скачать • Сохранить
• Комментарии отключены

Описание

• Introducing GPT-5

• Присоединяйтесь к Сэму Альтману, Грегу Брокману, Себастьену Бюбеку, Марку Чену, Янну Дюбуа, Брайану Фиоке, Ади Ганешу, Оливеру Годеману, Саачи Джайн, Кристине Каплан, Тине Ким, Элейн Я Ле, Фелипе Миллону, Мишель Покрасс, Якубу Пахоцки, Максу Шварцеру, Ренни Сонгу, Жожену Вану — они представят и продемонстрируют GPT‑5.

• OpenAI: Видео • О канале • Twitter • LinkedIn

• Участники обсуждают качество ИИ для повседневного программирования: один отмечает сильное превосходство Anthropic (Sonnet 3.7/4 и Claude Code), причём в Cursor опыт хуже, чем в самом Claude Code, и OpenAI‑модели он почти не использует.
• Есть надежда, что GPT‑5 сократит отставание OpenAI, хотя мнения пользователей сильно расходятся.
• Другой комментатор ожидает, что грядущие анонсы покажут радикальное влияние на рынок: веб‑ и JS/TS‑разработчики могут стать частично или полностью невостребованными.
• При этом подчёркивается, что речь ещё не об «AGI» — максимум о ~10% от обещанных возможностей AGI.
• Отмечается ночной «слив», указывающий на фокус на кодинге; предполагается, что для названия «GPT‑5» OpenAI должен предложить существенное преимущество над Anthropic.