Zhvillim i udhëhequr nga specifikimi për projektet me AI

AI e bën shumë më të lehtë prodhimin e shpejtë të kodit. Po aq e bën më të lehtë edhe prodhimin e shpejtë të kodit të gabuar. Pikërisht për këtë arsye zhvillimi i udhëhequr nga specifikimi është më i rëndësishëm, jo më pak i rëndësishëm, në projektet me ndihmën e AI.

Kur një ekip zhvillon pa një specifikim të qartë, produkti largohet me kohë nga qëllimi i tij. Kur në këtë proces ndihmon AI, ky devijim mund të ndodhë brenda një pasditeje. Kodi mund të kompilohet, ndërfaqja mund të duket e rregullt dhe testet mund të kalojnë. Produkti megjithatë mund të jetë i gabuar.

Pse AI ndryshon profilin e rrezikut

AI e përshpejton ritmin e interpretimit. Një kërkesë e vetme mund të prodhojë arkitekturë, tekst, validim, emërtim dhe rrjedhë përdoruesi. Kjo është e dobishme, por edhe e rrezikshme kur burimi i së vërtetës nuk është mjaftueshëm i qartë.

Në praktikë, AI shpesh optimizon atë që është më e dukshme në atë moment:

• kërkesën e fundit
• skedarin më të afërt
• rrugën më të lehtë të implementimit
• modelin më gjenerik të njohur

Asgjë nga këto nuk do të thotë vetvetiu vendim i saktë produkti.

Këto janë shkurtore të dobishme për gjenerim. Por nuk janë zëvendësim për gjykimin e produktit.

Çfarë bën një specifikim i mirë

Një specifikim i mirë kryen të paktën katër role:

• përcakton qëllimin
• vendos kufijtë
• përcakton standardin e shqyrtimit
• shërben si kujtesë e ekipit

Së pari, ai përcakton qëllimin. Ekipi mund të shohë nëse një veçori mbështet produktin real apo thjesht shton dalje.

Së dyti, ai përcakton kufijtë. Qartëson çfarë është në fushëveprim, çfarë është jashtë fushëveprimit, çfarë është opsionale dhe çfarë duhet të funksionojë edhe kur sistemet opsionale dështojnë.

Së treti, ai përcakton standardin e shqyrtimit. Në vend që të pyetet vetëm nëse një ndryshim funksionon teknikisht, shqyrtuesit mund të pyesin nëse ai përputhet me rrjedhën e synuar të punës dhe angazhimet e produktit.

Së katërti, ai vepron si kujtesë. Sistemet e AI nuk mbajnë vetë kujtesë institucionale të qëndrueshme. Një specifikim në depo po.

Kjo është shumë e qartë te Let Books. AGENTS.md thekson disa herë se rrjedha manuale duhet të funksionojë edhe pa shërbime AI me pagesë dhe se kopjet fizike të librave nuk janë e njëjta gjë me regjistrat bibliografikë. Këto nuk janë hollësi teknike, por kufij produkti.

Këto nuk janë hollësi implementimi. Janë kufij produkti. Nëse një ndihmës AI gjeneron një rrjedhë që bllokon futjen manuale ose shkrin të dhënat e kopjes fizike në metadata të botimit, problemi nuk është stili. Problemi është devijimi i produktit.

Pse dokumentimi nuk duhet të presë

Nëse dokumentimi është i vjetruar ose i paqartë, njerëz dhe mjete të ndryshme do të nxjerrin përfundime të ndryshme nga i njëjti depo. Njëri do të ndjekë demon, tjetri një README të vjetër, një tjetër skedarin më të afërt.

Pa dokumentim të përditësuar:

• kërkesat bëhen të paqëndrueshme
• shqyrtimi bëhet subjektiv
• demot fillojnë ta ripërcaktojnë produktin aksidentalisht
• kontribuesit e ardhshëm trashëgojnë sjellje pa e ditur nëse ajo ishte e qëllimshme

Prandaj dokumentimi nuk është vetëm shpjegim i mëvonshëm. Ai është pjesë e sistemit operativ të projektit. Në këtë depo, README.md përshkruan gjendjen aktuale, AGENTS.md qëllimin e produktit, AGENTS-Implementation.md rregullat taktike, ndërsa docs/ rregullat e publikimit dhe evidencës.

Roli i demove

Demoja është e dobishme sepse tregon çfarë ekziston dhe zbulon probleme në rrjedhën e përdoruesit. Por ajo nuk duhet të bëhet në heshtje specifikim produkti.

Rregullat e depos tashmë bëjnë dallimin mes specifikimeve dhe dokumentimit kanonik nga njëra anë dhe statusit të implementimit nga ana tjetër. Nëse demoja zbulon një rrjedhë më të mirë, duhet të përditësohen specifikimi dhe dokumentimi, jo të lihet demoja të fitojë vetë.

Nëse një demo zbulon një rrjedhë pune më të mirë, përgjigjja nuk është ta lëmë të fitojë në heshtje. Përgjigjja është të përditësohen specifikimi, dokumentimi dhe standardi i shqyrtimit që ajo rrjedhë më e mirë të bëhet e qëllimshme.

Markdown, testet dhe CI formojnë një zinxhir

Në një zhvillim të udhëhequr nga specifikimi, këto shtresa nuk qëndrojnë të ndara.

• Markdown ruan qëllimin në formë të shqyrtueshme.
• Dokumentimi shpjegon si duhet kuptuar ai.
• Testet verifikojnë pritjet e ekzekutueshme.
• Rregullat e validimit kapin devijimin strukturor.
• CI i zbaton rregullat rregullisht.

Së bashku ato krijojnë kujtesë produkti që i mbijeton shpejtësisë së zhvillimit.

Çdo shtresë është e paplotë më vete. Së bashku ato krijojnë kujtesë produkti që i mbijeton shpejtësisë, iterimit dhe ndryshimeve të ekipit.

Çfarë do të thotë kjo për ekipet që përdorin AI

Ekipet që e përdorin mirë AI nuk e heqin procesin. Ato e afrojnë procesin më pranë burimit të gjenerimit.

Kjo zakonisht do të thotë:

• të shkruajnë specifikime produkti më të qarta para implementimit
• të mbajnë të qarta udhëzimet e implementimit
• ta përditësojnë dokumentimin kur ndryshon sjellja e produktit
• t’i kontrollojnë demot kundrejt specifikimeve në vend që të supozojnë përputhje
• të shtojnë gradualisht rregulla validimi që përputhshmëria të mos varet vetëm nga kujtesa njerëzore

Kjo nuk është kundër AI. Kështu AI bëhet i besueshëm.

Mësimi i qëndrueshëm

AI mund të prodhojë shpejt kod, përmbajtje dhe ndërfaqe. Ai nuk mund të garantojë vetë që të gjitha këto dalje vazhdojnë të përshkruajnë të njëjtin produkt.

Zhvillimi i udhëhequr nga specifikimi është mënyra si një ekip e pengon shpejtësinë të kthehet në devijim.

Në projektet e asistuara nga AI, specifikimi nuk është burokraci pas faktit. Ai është kufiri, kujtesa dhe standardi i shqyrtimit që e bëjnë të besueshme dorëzimin e shpejtë.

Lexime të lidhura

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