Развој вођен спецификацијом за 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