Комментарии 5
Интересный способ. Пришел пока +- к тому же, но добавлю, что спецификацию можно покрывать тестами тоже, своеобразными тестами на понимание (задается сценарий, задается вопрос что будет), которые и люди тоже могут проходить периодически по срезам проекта. От языка спеки думаю зависит в том числе и сопоставимость с кодом. Когда агент пишет код по спеке, он опирается на те же конструкции что в ней, имена, уровни декомпозиции - поэтому код может быть таким же запутанным как код самой спеки или отходить от запланированного если спека нереалистичная (когда он начинает уже код исправлять и не говорит что сделал не так как в спеке например). На чем вы писали спецификации?
Спасибо! Сценарии написаны в Markdown в стиле Given/When/Then, API описан в OpenAPI, решения в ADR, а по сценариям есть приёмочные тесты, которые вызывают API, детали реализации им неважны. Плюс агент на каждом шаге дописывал отчёт в progress.md. Про зависимость кода от языка спеки очень точное наблюдение: у меня спеки разрослись в несколько раз больше кода, и агент опирался на них сильнее, а вот мое понимание как раз падало. Идея тестов на понимание по срезам проекта интересная. Попробую.
У меня был метод - писать скелет системы. Скелет отдельно - реализация отдельно. Разделены физически. Компоненты знают только скелет (контракты, интерфейсы), но не знают реализацию.
Но... В последнее время решил вайбкодить не думая о коде. Ждал что упрусь в потолок, после которого LLM-ка начнет водить по кругу. Пока не уперся. Пишет и пишет...
Однако другая проблема возникла - в моем недавнем проекте - дизассемблер в одном HTML-файле оффлайн - Клод отказался писать код, т.к. ему показалось что проект потенциально не безопасен. Вот и приехали...

ИИ‑агент захватил штурвал моего пет‑проекта. Возвращаю его с помощью интерактивных объяснений и двух промптов