Развој воден од спецификации за AI проекти

AI многу го олеснува брзото создавање код. Исто така многу го олеснува и брзото создавање погрешен код. Затоа развојот воден од спецификации е поважен, а не помалку важен, во проекти со помош на AI.

Кога тим работи без јасна спецификација, производот со време се оддалечува од својата цел. Кога во тоа помага AI, тоа може да се случи за едно попладне. Кодот може да се компајлира, интерфејсот може да изгледа уредно, а тестовите може да поминуваат. Производот сепак може да биде погрешен.

Зошто AI го менува профилот на ризик

AI го забрзува темпото на интерпретација. Еден упит може да произведе архитектура, текст, валидација, именување и кориснички тек. Тоа е корисно, но е опасно кога изворот на вистина не е доволно јасен.

Во пракса AI често го оптимизира она што во моментот е највидливо:

• последниот упит
• најблиската датотека
• најлесната патека за имплементација
• најгенеричниот познат образец

Ништо од тоа само по себе не значи исправна продуктна одлука.

Тоа се корисни кратенки за генерирање. Но тие не се замена за продуктна проценка.

Што прави добра спецификација

Добрата спецификација извршува најмалку четири задачи:

• ја дефинира целта
• поставува граници
• го одредува стандардот за преглед
• служи како меморија на тимот

Прво, ја дефинира целта. Тимот може да процени дали функцијата го поддржува вистинскиот производ или само додава излез.

Второ, ги дефинира границите. Појаснува што е во обем, што е надвор од обем, што е опционално и што мора да работи дури и кога опционалните системи откажуваат.

Трето, го дефинира стандардот за преглед. Наместо да се прашува само дали промената технички работи, рецензентите можат да прашаат дали се совпаѓа со наменетиот тек на работа и продуктните обврски.

Четврто, дејствува како меморија. AI системите сами по себе не држат стабилна институционална меморија. Спецификацијата во складиштето ја држи.

Тоа е многу јасно во Let Books. AGENTS.md повеќепати нагласува дека рачниот тек мора да работи и без платени AI услуги и дека физичките примероци книги не се исто што и библиографските записи. Тоа не се технички детали, туку продуктни граници.

Тоа не се имплементациски детали. Тоа се продуктни граници. Ако AI асистент генерира тек што го блокира рачниот внес или ги спојува податоците за физичкиот примерок со метаподатоците за изданието, проблемот не е стил. Проблемот е продуктно отстапување.

Зошто документацијата не смее да чека

Ако документацијата е застарена или нејасна, различни луѓе и различни алатки од истото складиште ќе заклучат дека постојат различни производи. Еден ќе го следи демото, друг стариот README, трет најблиската датотека.

Без актуелна документација:

• упитите стануваат недоследни
• прегледот станува субјективен
• демата почнуваат случајно да го редефинираат производот
• идните соработници наследуваат однесување без да знаат дали било намерно

Затоа документацијата не е само доцно објаснување. Таа е дел од оперативниот систем на проектот. Во ова складиште README.md ја опишува тековната состојба, AGENTS.md продуктната намера, AGENTS-Implementation.md тактичките правила, а docs/ правилата за објавување и евиденција.

Улогата на демото

Демото е корисно затоа што покажува што постои и открива проблеми во корисничкиот тек. Но не треба тивко да стане продуктна спецификација.

Правилата на складиштето веќе прават разлика меѓу канонска спецификација и документација од една страна и статус на имплементација од друга. Ако демото открие подобар тек, треба да се ажурираат спецификацијата и документацијата, а не да се дозволи демото само по себе да победи.

Ако демото открие подобар тек, одговорот не е тивко да му се дозволи да победи. Одговорот е да се ажурираат спецификацијата, документацијата и стандардот за преглед за подобриот тек да стане намерен.

Markdown, тестови и CI создаваат синџир

Во развој воден од спецификации овие слоеви не стојат одделно.

• Markdown ја чува намерата во прегледна форма.
• Документацијата објаснува како треба да се толкува.
• Тестовите проверуваат извршливи очекувања.
• Правилата за валидација фаќаат структурно отстапување.
• CI редовно ги спроведува правилата.

Заедно создаваат продуктна меморија што ја преживува брзината на развојот.

Секој слој е сам по себе нецелосен. Заедно создаваат продуктна меморија што ги преживува брзината, итерациите и промените во тимот.

Што значи ова за тимовите што користат AI

Тимовите што добро користат AI не го отстрануваат процесот. Тие го поместуваат процесот поблиску до изворот на генерирање.

Тоа обично значи:

• пред имплементација да пишуваат појасни продуктни спецификации
• да одржуваат изрични насоки за имплементација
• да ја ажурираат документацијата кога ќе се промени однесувањето на производот
• да ги проверуваат демата според спецификациите наместо да претпоставуваат усогласеност
• постепено да додаваат правила за валидација, така што усогласеноста да не зависи само од човечката меморија

Ова не е против AI. Вака AI станува доверлив.

Трајна лекција

AI може брзо да произведе код, содржина и интерфејси. Сам по себе не може да гарантира дека сите тие излези сè уште го опишуваат истиот производ.

Развојот воден од спецификации е начин тимот да спречи брзината да се претвори во отстапување.

Во AI-поддржани проекти спецификацијата не е бирократија по завршувањето. Таа е граница, меморија и стандард за преглед што ја прават брзата испорака доверлива.

Поврзано четиво

• ../../wiki/spec-driven-development.md
• ../../wiki/validation-layers.md
• ai-as-an-oracle.md
• spec-driven-development-in-let-books.md