GitHub — Spec Kit. Поки ми шукаємо стежки, основні гравці змінюють ландшафт
Близько тижня моя стрічка в YouTube забита черговою новинкою від GitHub — Spec Kit.
Пропонується приваблива ідея: від концепції «найкраща документація проєкту — це якісний, грамотно написаний код» перейти до практики «найкращий код — це повноцінна специфікація».
Передбачається, що на вхід подається, загалом-то, неформальне завдання, що описує, що має робити програма, навіщо вона потрібна і як її планують використовувати. Далі вмикається магія ШІ, і під управлінням людини виходять два артефакти: файл із планом реалізації та другий, детальний, з невеликими атомарними завданнями. За цими завданнями ШІ-агент без проблем згенерує повноцінний робочий код.
Це досягається завдяки поступовому накладанню обмежень та уточненню вимог через діалог із розробником. Як бонус ми маємо повноцінний комплект документації, що однозначно відповідає коду. Код = F(spec).
Далі, при зміні вимог, ми міняємо кілька пунктів у специфікації й отримуємо нову версію програми з необхідною поведінкою.
Цікавими є коментарі: від захоплених до радикально-скептичних. Ось один із них:
«Невже замовнику тепер доведеться писати ті самі повні специфікації, про які розробники благали роками? Невже це кінець епохи „зробіть, а там розберемося“? Невже доведеться працювати правильно?»
Звідки стільки скепсису? Що ж може піти не так?
Так уже сталося, що мені вдалося «винайти» схожу методологію на кілька місяців раніше. На етапі впровадження я зіткнувся з такими проблемами.
По-перше, розробник не навчений створювати специфікацію, його робота — чітко її дотримуватися. Через це її валідація була фактично відсутня.
По-друге, спроба провести верифікацію новостворенного "Плану” показала, що перевірити специфікацію складніше, ніж згенерований код. Я припускаю, що проблема є комплексною. Код простіше токенізувати, розбити на семантичні конструкції, він формалізований і звичний для розробника. Його недоліки очевидні, а для верифікації коду існує звичний інструментарій, що формувався десятиліттями. Специфікація в цьому сильно програє: навіть md-форматування виглядає суцильним текстом порівняно програмним кодом. Додає проблем той факт що один і той самий промпт буде реалізований по-різному різними LLM.
Гадаю, зараз ентузіасти використання ШІ для розробки перебувають у тій самій ситуації, що й перші програмісти епохи перфокарт. Недарма більшість інструментів нагадують консольні застосунки часів PDP-11.
Далі — гірше. Імовірність правильного розв'язання задачі для найкращих моделей коливається в межах 50% (можете самостійно вивчити цей звіт). Наявне завдання проходить кілька етапів, результатом кожного з яких є полотно погано структурованого тексту. Помилки та галюцинації не блокувалися, а перетікали на наступний рівень і змішувалися з новими. Таким чином, для триетапного процесу загальна ймовірність успіху падає до 12,5% (0.5 × 0.5 × 0.5).
Це означає, що в 9 з 10 випадків специфікація міститиме проблему. Щоб виправити ситуацію з пропущеними даними, ми додали в промпт метрику покриття вимог із попереднього рівня. Це допомогло зрушити процес з мертвої точки, але потім виникла нова складність. Помилка в специфікації, виявлена на етапі генерації коду або налагодження, вимагала зупинки та повернення всього процесу до попереднього етапу. Найчастіше цим не обмежувалося, і все поверталося на самий початок. Увесь цей цикл створював враження незграбного зомбі.
У підсумку виявилося, що в моєму випадку простіше й надійніше передавати розробнику вимоги у вигляді класичного PRD-файла. В якості агента використовується розширення RooCode для VS Code. Короткий цикл підключає до процесу розробника, а всі доопрацювання відображаються безпосередньо у змінах PRD-файла.
Однак це не означає, що Spec Kit має всі ті самі проблеми. Думаю, я протестую його на одній з найближчих ітерацій і поділюся враженнями.