Hacker News Digest

Spec-Driven Development (SDD) возрождает подход Waterfall с подробной документацией перед кодированием. Хотя он обещает структуру для ИИ-программирования, рискует погребать гибкость под слоями Markdown. Инструменты вроде Spec-Kit, Kiro и Tessl генерируют спецификации в виде Markdown-файлов, где даже простая функция может требовать 8 файлов и 1300 строк текста.

Процесс SDD создает цепочку документов: от первоначального запроса через спецификации к плану реализации и списку задач. Эти документы затем передаются кодирующему агенту (Claude Code, Cursor, Copilot), который должен написать качественный код. Однако автор сомневается, что такой формальный подход лучше подходит для современной разработки, предлагая вместо этого более итеративный подход с использованием естественного языка.

• Спор вокруг Spec-Driven Development (SDD) в контексте LLM: одни считают, что спецификация — это лишь «точка входа» для модели, другие же видят в ней водопадную модель разработки.
• Сторонники SDD подчеркивают, что спецификация позволяет избежать «vibe-coding» и снижает количество багов, а критики указывают на то, что писать спецификации сложнее, чем код, и что она не покрывает итеративную разработку.
• Обсуждение затронуло TDD и Event-B как смежные практики, а также подняло вопрос о том, как именно спецификация должна выглядеть: как полноценный документ или как краткий конспект.

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