Како прегледати рад уз помоћ AI у односу на спецификацију

Зашто је то важно

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

Та брзина ствара ризик при прегледу: особе које прегледају могу несвесно прећи са питања „Да ли је ово исправно понашање производа?“ на питање „Да ли ово делује разумно?“.

То нису иста питања.

У раду вођеном спецификацијама преглед би требало да почне од усклађености, а тек затим да пређе на квалитет кода, стил и детаље имплементације.

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

Пре него што прегледате излаз, идентификујте документе који дефинишу жељено понашање.

У Let Books репозиторијуму то обично значи:

• AGENTS.md за правила производа, токове рада и обим
• AGENTS-Implementation.md за тактичка ограничења испоруке
• README.md за приказ тренутног стања
• релевантну документацију под docs/ за објављивање, верификацију или смернице тока рада

Без овог корака преглед лако постаје субјективан и локалан.

Прегледајте правим редоследом

Користите овај редослед када прегледате рад уз помоћ AI.

1. Усклађеност са производом

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

Примери:

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

Ако је усклађеност са производом погрешна, нема много вредности у томе да се прво троши много времена на дотеривање.

2. Усклађеност са документацијом

Питајте да ли околна документација и даље поштено описује стварност.

Примери:

• да ли је кориснику видљив ток рада промењен без ажурирања документације
• да ли README и даље исправно описује тренутно стање
• да ли се нове јавне тврдње поклапају са стварно документованом позицијом производа

Промене које генерише AI често промене понашање, а да се не ажурира наратив око тог понашања.

3. Валидација и резервно понашање

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

Примери:

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

Овде многе уверљиве имплементације падају на стварном тесту производа.

4. Технички квалитет

Тек након претходних провера треба посветити највећи део времена:

• јасноћи
• одрживости
• именовању
• дуплирању
• тестовима
• структури

Технички квалитет је и даље важан. Само не би требало да буде важнији од исправности производа.

Честе замке при прегледу

Рад уз помоћ AI има тенденцију да ствара неколико поновљивих замки при прегледу.

Замка углађеног излаза

Излаз изгледа чисто, па особе које прегледају претпоставе да је исправан.

Замка оближњег контекста

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

Замка имплицитног обима

Асистент дода функције, апстракције или претпоставке које никада нису тражене, а прегледалац их прихвати јер не делују очигледно покварено.

Замка пролазних тестова

Тестови могу пролазити зато што валидирају генерисано понашање, а не зато што валидирају намеравано понашање производа.

Практична контролна листа за преглед

За сваку значајнију промену уз помоћ AI питајте:

1. Које правило производа или који ток рада ова промена треба да имплементира?
2. Која спецификација или документација дефинише то правило?
3. Да ли излаз чува тражена ограничења?
4. Да ли задржава резервно понашање нетакнутим?
5. Да ли се документација и даље поклапа са резултујућим понашањем?
6. Која валидација или тестови подржавају промену?
7. Да ли је асистент додао нешто што би требало уклонити као ван обима?

Како прегледати генерисане тестове

Генерисани тестови су корисни, али и њих треба прегледати у односу на спецификацију.

Питајте:

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

То је посебно важно у раду вођеном спецификацијама, јер слаб тестни скуп може да учврсти одступање.

Примери из Let Books

Примери питања на нивоу спецификације у овом репозиторијуму укључују:

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

Та питања су довољно конкретна да усмеравају преглед, што је управо оно што спецификација треба да омогући.

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

Преглед уз помоћ AI није у томе да проверите да ли је асистент произвео нешто импресивно. Ради се о томе да проверите да ли излаз и даље припада намераваном производу.

Најбоље питање при прегледу обично није „Да ли ово ради?“. Оно је „Да ли се ово поклапа са спецификацијом, укључујући делове које је лако заборавити?“.

Даље читање

• ../spec-driven-content-program.md
• how-to-write-a-spec-that-ai-can-follow.md
• how-to-turn-a-product-spec-into-an-implementation-plan.md
• how-to-keep-spec-docs-demo-and-code-aligned.md
• ../wiki/sr-Cyrl/spec-driven-development.md
• ../blog/sr-Cyrl/spec-driven-development-for-ai-projects.md