Создать правильную спецификацию с первой попытки не удастся, и даже Fable в этом не поможет.
В блоге Anthropic появился материал Thariq Shihipar, где он делится опытом: как агент помогает ему выявлять Неизвестные Неизвестные (Unknown Unknowns). Эти идеи напрямую касаются подхода Spec Driven Development. Они наглядно демонстрируют, что спецификация — не статичный документ, а живой, который обретает завершённость лишь к моменту написания кода (а то и после). Если Spec Driven Development кажется вам перспективным направлением AI-assisted разработки, давайте разберёмся подробнее.
Отправная точка проста: карта никогда не равна местности. В контексте разработки наша задача перед агентом — как раз эта самая карта. А разрыв между схемой и реальным маршрутом складывается из неизвестностей (unknowns). Каждая из них — место, где агенту приходится строить догадки. Автор выделяет четыре разновидности: известные известные (known knowns) — то, что вы способны сформулировать как намерение; известные неизвестные (known unknowns) — пробелы, о которых вы знаете; неизвестные известные (unknown knowns) — настолько очевидные вещи, что их никогда не записывают; и наконец, неизвестные неизвестные (unknown unknowns) — то, чего вы даже не представляли.
Вот в чём загвоздка: спецификация, составленная за один подход, охватывает лишь первую категорию. Остальные три категории находятся не в вашей голове, а в той самой местности. Пройти её — единственный способ нанести на карту реальность. Убеждение, что спецификация является готовым чертежом, — ошибка. Вы не пишете её и не передаёте агенту. Вы делаете черновик, который меняется по мере совместного с агентом продвижения: открываются технические и бизнесовые детали. Динамичная спецификация — признак здорового подхода.
Процесс стартует с намерения: вы фиксируете известные известные, первого наброска достаточно, чтобы наметить вектор. Затем агент исследует местность — изучает ваш код, базу знаний (например, через MCP) и вытаскивает то, что вы упустили. На этом этапе чинится значительная часть первого черновика. Механизм комментирования кода и спецификаций в SpecBuddy делает этот процесс гораздо удобнее, чем переписка в чате. Далее вы совместно создаёте план с учётом открывшихся обстоятельств. Запуская его, вы постоянно сталкиваетесь с новыми граничными случаями и ограничениями. Тогда возвращаетесь и перерисовываете карту: граничный случай уходит в спецификацию, решение фиксируется. Так повторяется многократно — первый «верный» вариант невозможен, потому что вы ещё ни разу не прошли по маршруту. Когда работа завершена, спецификация наконец совпадает с реальной местностью. Коммитьте её вместе с кодом. Через полгода кто-то задаст вопрос, почему фича работает именно так, и ответ будет лежать на виду в спецификации: изначальные цели, находки агента, граничные случаи и принятые решения. С первого раза идеально не получится, но перерисовывая карту по ходу, вы создаёте нечто ценнее «изначально верного» документа — карту, действительно совпадающую с местностью, которая останется в проекте надолго.
Загрузка...
