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 как смежные практики, а также подняло вопрос о том, как именно спецификация должна выглядеть: как полноценный документ или как краткий конспект.

Спецификация, а не код, становится главным артефактом: разработка начинается с написания спецификации, которая затем используется для генерации кода. Это позволяет ускорить разработку, особенно с помощью AI, и повысить качество за счёт чётких требований. Однако есть риск, что спецификация устареет при изменении кода, что требует синхронизации. В целом, подход обещает повысить эффективность, но требует тщательного управления.

• Обсуждение вращается вокруг "spec-anchored" подхода: от использования спецификаций как единственного источника правды до практических вопросов, таких как разделение труда между человеком и ИИ, и как спецификация может эволюционировать в процессе разработки.
• Участники делятся опытом использования таких инструментов как SpecKit и Plotly Studio, подчеркивая, что спецификация должна быть лаконичной, но исчерпывающей, чтобы быть полезной.
• Обсуждается, как спецификация может быть использована для управления проектом, но также вызывает тревогу, что без должного контроля она может стать неактуальной или чрезмерно сложной.
• Поднимается вопрос о том, как спецификация должна эволюционировать вместе с проектом, и как она должна отражать реальные условия и требования, даже если эти требования еще не полностью ясны.
• Заключается, что хотя инструменты могут и должны быть использованы для автоматизации части работы, важно оставить пространство для человеческого суждения и творчества, и что спецификация сама по себе не должна быть чрезмерно сложной или непрактичной.

oq — консольный просмотрщик OpenAPI-спецификаций.
Быстро открывает swagger.json|yaml в терминале, показывает эндпоинты, параметры, примеры ответов.
Установка: go install github.com/plutov/oq@latest.
Использование: oq spec.yaml.

• Утилита «oq» — терминальный просмотрщик OpenAPI-спецификаций, упрощающий навигацию по большим YAML/JSON.
• Пользователи практикуют spec-driven development: спецификация = единый источник правды, из неё генерируют типизированный клиент и сервер.
• Название «oq» уже занято другим проектом (homebrew-установка ставит не тот пакет); автор пока не переименовывает, предлагает брать бинарь с GitHub-релизов.
• Поддержка OpenAPI 3.1 заявлена, но реализована поверх библиотеки kin-openapi, которая 3.1 пока не умеет; для простого листинга маршрутов и компонентов это работает.
• В планах — добавить возможность делать реальные HTTP-запросы прямо из viewer.