Si të rishikoni punë të ndihmuar nga AI kundrejt specifikimit

Pse kjo ka rëndësi

AI mund të prodhojë shumë shpejt kod, tekst, teste dhe ndryshime të ndërfaqes që duken të plota.

Kjo shpejtësi krijon një rrezik rishikimi: rishikuesit mund të kalojnë pa e kuptuar nga pyetja “A është kjo sjellja e duhur e produktit?” te pyetja “A duket kjo e arsyeshme?”.

Këto nuk janë e njëjta pyetje.

Në punën e drejtuar nga specifikimet, rishikimi duhet të fillojë me përafrimin dhe vetëm pastaj të kalojë te cilësia e kodit, stili dhe hollësitë e implementimit.

Filloni me burimin e së vërtetës

Përpara se të rishikoni rezultatin, identifikoni dokumentet që përcaktojnë sjelljen e synuar.

Në depon Let Books, kjo zakonisht do të thotë:

• AGENTS.md për rregullat e produktit, rrjedhat e punës dhe shtrirjen
• AGENTS-Implementation.md për kufizimet taktike të dorëzimit
• README.md për paraqitjen e gjendjes aktuale
• dokumentacionin përkatës nën docs/ për publikim, verifikim ose udhëzime rrjedhe pune

Pa këtë hap, rishikimi bëhet lehtësisht subjektiv dhe lokal.

Rishikoni në rendin e duhur

Përdoreni këtë rend kur rishikoni punë të ndihmuar nga AI.

1. Përafrimi me produktin

Pyesni nëse rezultati përputhet me rrjedhën e synuar të përdoruesit dhe kufirin e produktit.

Shembuj:

• a vazhdon të funksionojë hyrja manuale atje ku e kërkon specifikimi
• a e ruan ndryshimi ndarjen midis kopjeve fizike dhe regjistrave bibliografikë
• a shton sjellje që nuk u miratuan kurrë
• a i paraqet gabimisht veçoritë opsionale të AI si të detyrueshme

Nëse përafrimi me produktin është i gabuar, nuk ka shumë vlerë të shpenzohet kohë për lustrim fillimisht.

2. Përafrimi me dokumentacionin

Pyesni nëse dokumentacioni rreth ndryshimit vazhdon ta përshkruajë realitetin me ndershmëri.

Shembuj:

• a u ndryshua një rrjedhë pune e dukshme për përdoruesin pa u përditësuar dokumentacioni
• a e përshkruan ende README-ja saktë gjendjen aktuale
• a përputhen pretendimet e reja publike me pozicionin e dokumentuar real të produktit

Ndryshimet e gjeneruara nga AI shpesh ndryshojnë sjelljen pa e përditësuar rrëfimin rreth asaj sjelljeje.

3. Validimi dhe sjellja rezervë

Pyesni nëse ndryshimi i ruan pritjet për dështim dhe sjellje rezervë nga specifikimi.

Shembuj:

• a mund të ketë ende sukses rrjedha e punës kur dështon një ofrues opsional
• a trajtohen në mënyrë eksplicite hyrjet e pavlefshme
• a trajtohen si sugjerime dhe jo si fakte rezultatet me besueshmëri të ulët ose të pasigurta

Këtu dështojnë shumë implementime të besueshme në testin real të produktit.

4. Cilësia teknike

Vetëm pas kontrolleve të mësipërme duhet të shpenzoni pjesën më të madhe të kohës te:

• qartësia
• mirëmbajtshmëria
• emërtimi
• dublimi
• testet
• struktura

Cilësia teknike ka ende rëndësi. Thjesht nuk duhet të jetë më e rëndësishme se korrektësia e produktit.

Kurthe të zakonshme rishikimi

Puna e ndihmuar nga AI priret të krijojë disa kurthe rishikimi të përsëritshme.

Kurthi i rezultatit të lëmuar

Rezultati duket i pastër, prandaj rishikuesit supozojnë se është i saktë.

Kurthi i kontekstit të afërt

Ndryshimi përputhet me implementimin ekzistues më të afërt, por ai implementim i afërt mund të ketë devijuar tashmë.

Kurthi i shtrirjes së nënkuptuar

Ndihmësi shton veçori, abstraksione ose supozime që nuk u kërkuan kurrë, dhe rishikuesi i pranon sepse nuk duken qartazi të prishura.

Kurthi i testeve që kalojnë

Testet mund të kalojnë sepse validon sjelljen e gjeneruar, jo sepse validon sjelljen e synuar të produktit.

Një listë praktike rishikimi

Për çdo ndryshim të rëndësishëm të ndihmuar nga AI, pyesni:

1. Cilin rregull produkti ose cilën rrjedhë pune supozohet të implementojë ky ndryshim?
2. Cili specifikim ose dokumentacion e përcakton atë rregull?
3. A i ruan rezultati kufizimet e kërkuara?
4. A e mban të paprekur sjelljen rezervë?
5. A përputhet ende dokumentacioni me sjelljen që rezulton?
6. Cili validim ose cilat teste e mbështesin ndryshimin?
7. A shtoi ndihmësi diçka që duhet hequr si jashtë shtrirjes?

Si të rishikoni testet e gjeneruara

Testet e gjeneruara janë të dobishme, por edhe ato duhen rishikuar kundrejt specifikimit.

Pyesni:

• a kontrollojnë testet rrjedhën e synuar të punës
• a mbulojnë sjelljen rezervë
• a pasqyrojnë kushtet kufitare të dokumentuara
• a po pohojnë një sjellje komoditeti që nuk u specifikua kurrë

Kjo është veçanërisht e rëndësishme në punën e drejtuar nga specifikimet sepse një paketë testesh e dobët mund ta ngurtësojë devijimin.

Shembuj nga Let Books

Shembuj të pyetjeve në nivel specifikimi në këtë depo përfshijnë:

• a mbetet rrjedha e punës e dobishme pa shërbime AI me pagesë
• a e ndan qartë dokumentacioni i gjendjes aktuale statusin e demonstrimit nga planet e ardhshme për backend-in
• a shmang dokumentacioni publik trajtimin e kodit burimor si provë editoriale kanonike
• a mbeten hapat e validimit pjesë e rrjedhës së dorëzimit në vend që të varen nga kujtesa opsionale

Këto pyetje janë mjaftueshëm specifike për të drejtuar rishikimin, dhe kjo është pikërisht ajo që duhet të mundësojë një specifikim.

Mësimi afatgjatë

Rishikimi i ndihmuar nga AI nuk ka të bëjë me kontrollimin nëse ndihmësi prodhoi diçka mbresëlënëse. Ka të bëjë me kontrollimin nëse rezultati ende i përket produktit të synuar.

Pyetja më e mirë e rishikimit zakonisht nuk është “A funksionon kjo?”. Është “A përputhet kjo me specifikimin, përfshirë pjesët që harrohen lehtë?”.

Lexim i mëtejshëm

• ../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/sq/spec-driven-development.md
• ../blog/sq/spec-driven-development-for-ai-projects.md