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

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