Hacker News Digest

Anthropic представила Claude Code в веб-интерфейсе, позволяющий выполнять кодирование прямо из браузера. Сервис находится в бета-версии как исследовательский превью и позволяет назначать несколько задач, которые выполняются на облачной инфраструктуре Anthropic. Ключевая возможность — параллельное выполнение задач в изолированных средах с отслеживанием прогресса в реальном времени. Пользователи могут подключать репозитории GitHub, описывать требования, а Claude самостоятельно реализует решения, создавая автоматические pull requests с подробными сводками изменений.

Веб-интерфейс дополняет существующую рабочую среду Claude Code, особенно эффективен для ответов на вопросы о проектах, исправления багов и рутинных задач, а также для бэкенд-изменений с использованием TDD. Каждая задача выполняется в защищенном песочном окружении с ограничениями сети и файловой системы, а взаимодействие с Git осуществляется через безопасный прокси. Сервис уже доступен для Pro и Max пользователей, а также появился в iOS-приложении в виде ранней версии.

• Обсуждение охватывает широкий спектр тем: от сравнения Claude Code и Codex, до вопросов о лицензии, инфраструктуре и будущих функциях.
• Участники обсуждают, какие инструменты лучше подходят для разных задач: Claude Code для итеративной работы и Codex для надежности при критически важных задачах.
• Также обсуждается, что пользователи хотели бы видеть более тесную интеграцию с GitHub Actions, API и другими сервисами.
• Некоторые комментаторы выражают обеспокоенность по поводу ограничений доступа к сети и отсутствия поддержки Docker.
• В то же время, другие участники подчеркивают, что Anthropic и OpenAI продолжают развивать свои инструменты, и что выбор между ними часто сводится к личным предпочтениям и конкретным сценариям использования.

Качество ПО, создаваемого с помощью ИИ, зависит от управления единицами работы. Основная проблема — не интеллект моделей, а предоставление правильного контекста.

Андрей Карпати описал работу ИИ-инженера как «держать ИИ на коротком поводке». Это означает разбивать задачи на небольшие конкретные части.

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

Правильный размер единицы работы контролирует распространение ошибок. При 5% вероятности ошибки за шаг, после 10 шагов шанс успеха падает до 59,9%. Современные модели, такие как GPT-5, демонстрируют успех в 70% для длительных задач, но это достигается в стабильных средах, тогда как реальные задачи часто происходят в изменяющихся условиях.

• Оптимальный размер задач для ИИ-агентов — небольшие, хорошо скоупленные единицы работы, аналогичные традиционному управлению проектами.
• Ключевые сложности: формулировка требований на естественном языке, проверка сгенерированного кода и поддержание контекста.
• Эффективная стратегия — работа в коротких сессиях с очисткой контекста и использованием саммари между задачами.
• Мнения о прогрессе инструментов разделились: одни отмечают значительный скачок в качестве, другие — лишь постепенные улучшения.
• Агенты пока надежно справляются только с простыми, «интерн-уровневыми» задачами, требуя постоянного контроля.
• Популярные методики: TDD (разработка через тестирование) и декомпозиция крупных задач на более мелкие планы.
• Аналогии со строительством дома признаются спорными, так как разработка ПО — итеративный, а не линейный процесс.

Погружён в технический долг
Книга-манифест о том, как разработчики и компании увязают в «техдолге» и выбираются из него.

• Что такое техдолг?
  Упрощения в коде, которые экономят время сейчас, но замедляют работу потом.

• Почему он растёт?
  Жёсткие дедлайны, отсутствие тестов, «потом поправим».

• Как измерить?
  Метрики времени на исправление багов, частота откатов, удовлетворённость команды.

• Как уменьшить?

  1. Выделять 20 % времени на рефакторинг.
  2. Писать тесты до кода (TDD).
  3. Проводить ревью каждого PR.
  4. Удалять мёртвый код.

• Культура
  Признайте проблему публично, отпразднуйте первый «день выплаты долга».

• Читатели спорят: кто-то хвалит тему и пользу книги, кто-то ругает «воду», анекдотичность и сомневается в ИИ-авторстве.
• Критикуют метафору «плавание против течения» и длинные главы; просят внятную структуру и кликабельное оглавление.
• Автор (loumf): 18 месяцев писал без ИИ, 4 раунда редакторов, половина текста за 1 $ – чтобы покупали только заинтересованные.
• Печать через месяц; Show HN подача съехала в обычную.
• Вывод: тема ценна, но подача и навигация пока спорны – автор собирает конструктив и правит.

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

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

Решение — план-документ. Первым шагом прошу 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 %» к качеству.

Почему LLM не могут строить ПО

Эффективный инженер постоянно прокручивает цикл:

1. формирует ментальную модель требований,
2. пишет код,
3. проверяет, что он реально делает,
4. сверяет модели и правит код или требования.

LLM умеют писать и обновлять код, запускать тесты, логировать, но не умеют держать в голове ясную модель. Они путаются: считают, что всё работает, не понимают, где ошибка — в коде или в тесте, и при раздражении сносят всё и начинают заново. Человек же, столкнувшись с проблемой, может «свернуть» контекст, сфокусироваться на детали, затем вернуться к общей картине.

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

LLM полезны: быстро генерируют код и документацию, справляются с простыми задачами. В сложных случаях человек всё равно должен контролировать требования и проверять результат. В Zed верят в совместную работу человека и агента, но руль остаётся за инженером, а LLM — лишь инструмент.

• LLM хороши как инструменты-ассистенты: быстро пишут boilerplate, находят мелкие ошибки, экономят время на рутине.
• Главный недостаток — неспособность удерживать и «поддерживать» целостную ментальную модель задачи; контекст «размывается» или меняется непредсказуемо.
• Поэтому при росте кодовой базы отладка превращается в «чтение спагетти», и инженер всё равно вынужден начинать заново.
• Решение — не «больше контекста», а системы-обёртки: TDD-циклы, пошаговое планирование, документация-модель, строгие промпты.
• Вывод: сейчас LLM заменяют джунов и Google-поиск, но полноценное ПО без человека, который держит «теорию» проекта в голове, построить не могут.

Задача: перенести 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 хорош для разовых скриптов.
• Нет единой метрики: из-за недетерминированности моделей и субъективных критериев «хорошего кода» каждый получает разные результаты.

• Чёткое ТЗ — пишу заранее, чтобы агент видел контекст.
• Файл-инструкция по запуску линтервов и сборки.
• Саморевью — прошу 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 собственных патчей самим агентом.
• Некоторые вообще отказались от спецификаций: инкрементально подсказывают «следующий шаг, какой сделал бы я», сразу коммитят дифф и правят на лету.