Inxhinieria e Harness: përdorimi i Codex në një botë agjentike

Gjatë pesë muajve të fundit, ekipi ynë ka kryer një eksperiment: ndërtimin dhe shpërndarjen e një versioni beta të brendshëm të një produkti softuerik me 0 rreshta kodi të shkruar manualisht.

Produkti ka përdorues të përditshëm të brendshëm dhe testues alfa të jashtëm. Dërgohet, vendoset, prishet dhe rregullohet. Ajo që është ndryshe është se çdo rresht kodi—logjika e aplikacionit, testet, konfigurimi i CI, dokumentacioni, vëzhgueshmëria dhe mjetet e brendshme—është shkruar nga Codex. Ne vlerësojmë se e ndërtuam këtë në rreth 1/10 e kohës që do të ishte dashur për ta shkruar kodin me dorë.

Njerëzit drejtojnë. Agjentët veprojnë.

Ne e zgjodhëm qëllimisht këtë kufizim që të ndërtonim atë që ishte e nevojshme për të rritur shpejtësinë e inxhinierisë me disa herë. Kishim javë të tëra për të dërguar atë që përfundoi si një milion rreshta kodi. Për ta bërë këtë, na duhej të kuptonim se çfarë ndryshon kur puna kryesore e një ekipi inxhinierie softuerike nuk është më të shkruajë kod, por të projektojë mjedise, të specifikojë qëllimin dhe të ndërtojë cikle reagimi që u lejojnë agjentëve të Codex të kryejnë punë të besueshme.

Ky postim është për atë që mësuam duke ndërtuar një produkt të ri me një ekip agjentësh — çfarë u prish, çfarë u përkeqësua dhe si të maksimizojmë burimin tonë të vetëm vërtet të pakët: kohën dhe vëmendjen njerëzore.

Commit-i i parë në një depo bosh u krye në fund të gushtit 2025.

Skela fillestare — struktura e depo, konfigurimi i CI, rregullat e formatimit, konfigurimi i menaxherit të paketave dhe korniza e aplikacionit — u gjenerua nga Codex CLI duke përdorur GPT‑5, e udhëhequr nga një grup i vogël shabllonesh ekzistuese. Edhe skedari fillestar AGENTS.md që udhëzon agjentët se si të punojnë në depo ishte shkruar nga vetë Codex.

Nuk kishte kod të shkruar më parë nga njerëzit për të shërbyer si bazë për sistemin. Që nga fillimi, depo u formësua nga agjent.

Pesë muaj më vonë, depoja përmban rreth një milion rreshta kodi në logjikën e aplikacionit, infrastrukturë, mjete, dokumentacion dhe shërbime të brendshme për zhvilluesit. Gjatë asaj periudhe, afërsisht 1500 pull request janë hapur dhe shkrirë, me një ekip të vogël prej vetëm tre inxhinierësh që drejtojnë Codex. Kjo përkthehet në një kapacitet përpunimi mesatar prej 3,5 PRs për inxhinier në ditë, dhe çuditërisht kapaciteti është rritur ndërsa ekipi është zgjeruar dhe tani përbëhet nga shtatë inxhinierë. E rëndësishme, kjo nuk ishte prodhim për hir të prodhimit: produkti është përdorur nga qindra përdorues brenda organizatës, duke përfshirë përdorues të fuqishëm të brendshëm që e përdorin çdo ditë.

Gjatë gjithë procesit të zhvillimit, njerëzit nuk kontribuuan kurrë drejtpërdrejt me kod. Kjo u bë një filozofi thelbësore për ekipin: asnjë kod i shkruar me dorë.

Mungesa e kodimit praktik nga njerëzit prezantoi një lloj tjetër pune inxhinierike, të përqendruar te sistemet, strukturat mbështetëse dhe shfrytëzimi.

Përparimi fillestar ishte më i ngadalshëm nga sa prisnim, jo sepse Codex ishte i paaftë, por sepse mjedisi ishte i papërcaktuar mirë. Agjentit i mungonin mjetet, abstraksionet dhe struktura e brendshme e nevojshme për të bërë përparim drejt qëllimeve të nivelit të lartë. Detyra kryesore e ekipit tonë inxhinierik u bë të mundësojmë agjentët të kryejnë punë të dobishme.

Në praktikë, kjo nënkuptonte të punohej në mënyrë të thelluar: të zbërtheheshin qëllimet më të mëdha në blloqe ndërtimi më të vogla (dizajn, kod, rishikim, test, etj.), duke i kërkuar agjentit të ndërtonte ato blloqe dhe t'i përdorte ato për të zhbllokuar detyra më komplekse. Kur diçka dështonte, zgjidhja pothuajse kurrë nuk ishte “përpiqu më shumë.” Meqenëse e vetmja mënyrë për të bërë përparim ishte të bënim që Codex të kryente punën, inxhinierët njerëzorë gjithmonë ndërhynin në detyrë dhe pyesnin: “cilat aftësi mungojnë dhe si t'i bëjmë ato të lexueshme dhe të zbatueshme për agjentin?”

Njerëzit ndërveprojnë me sistemin pothuajse tërësisht përmes kërkesave: një inxhinier përshkruan një detyrë, ekzekuton agjentin dhe e lejon atë të hapë një pull request. Për të përfunduar një PR, ne udhëzojmë Codex të rishikojë ndryshimet e veta lokalisht, të kërkojë rishikime shtesë specifike nga agjentët si lokalisht ashtu edhe në cloud, t’u përgjigjet çdo komenti të dhënë nga njerëzit ose agjentët, dhe të përsërisë në një cikël derisa të gjithë agjentët rishikues të jenë të kënaqur (në thelb kjo është një Ralph Wiggum Loop⁠(hapet në një dritare të re)). Codex përdor drejtpërdrejt mjetet tona standarde të zhvillimit (gh, skriptet lokale dhe aftësitë e integruara në depo) për të mbledhur kontekst pa pasur nevojë që njerëzit të kopjojnë dhe ngjisin në CLI.

Njerëzit mund të shqyrtojnë pull request, por nuk janë të detyruar ta bëjnë. Me kalimin e kohës, kemi orientuar pothuajse të gjithë përpjekjen e rishikimit drejt trajtimit nga agjenti te agjenti.

Ndërsa kapaciteti i përpunimit të kodit u rrit, ngushtica jonë u bë kapaciteti njerëzor për kontrollin e cilësisë. Meqenëse kufizimi i fiksuar ka qenë koha dhe vëmendja njerëzore, kemi punuar për t’i shtuar më shumë aftësi agjentit duke i bërë elemente si ndërfaqja e përdoruesit të aplikacionit, regjistrat dhe metrikat e aplikacionit vetë drejtpërdrejt të lexueshme për Codex.

Për shembull, e bëmë aplikacionin të nisshëm për çdo degë pune të git, që Codex të mund të niste dhe të drejtonte një instancë për çdo ndryshim. Ne gjithashtu integruam Protokollin e Chrome DevTools në kohën e ekzekutimit të agjentit dhe krijuam aftësi për të punuar me pamjet e çastit të DOM-it, pamjet e ekranit dhe navigimin. Kjo i mundësoi Codex të riprodhonte gabimet, të verifikonte rregullimet dhe të arsyetonte drejtpërdrejt për sjelljen e ndërfaqes së përdoruesit.

Ne bëmë të njëjtën gjë për mjetet e monitorimit. Regjistrat, matjet dhe gjurmët janë të aksesueshme nga Codex përmes një strukture lokale të observueshmërisë që është e përkohshme për çdo worktree të caktuar. Codex funksionon në një version plotësisht të izoluar të atij aplikacioni — duke përfshirë regjistrat dhe metrikat e tij, të cilat çmontohen sapo të përfundojë ajo detyrë. Agjentët mund të kërkojnë regjistrat me LogQL dhe metrikat me PromQL. Me këtë kontekst të disponueshëm, kërkesa si “sigurohu që nisja e shërbimit të përfundojë në më pak se 800ms” ose “asnjë hap në këto katër rrugëtime kritike të përdoruesit të mos e kalojë dy sekonda” bëhen të realizueshme.

Ne shpesh shohim që Codex ekzekuton një detyrë të vetme për më shumë se gjashtë orë (shpesh ndërsa njerëzit flenë).

Menaxhimi i kontekstit është një nga sfidat më të mëdha për t'i bërë agjentët efikasë në detyra të mëdha dhe komplekse. Një nga mësimet më të hershme që mësuam ishte i thjeshtë: jepi Codex një hartë, jo një manual udhëzimesh me 1 000 faqe.

Ne provuam “një AGENTS.md⁠(hapet në një dritare të re) të madh” qasje. Dështoi në mënyra të parashikueshme:

• Konteksti është një burim i rrallë. Një skedar gjigant udhëzimesh e zë vendin e detyrës, kodit dhe dokumenteve përkatëse — kështu që agjent ose humbet kufizime kyçe ose fillon të optimizojë për ato të gabuara.
• Shumë udhëzime bëhen mos-udhëzime. Kur gjithçka është “e rëndësishme”, asgjë nuk është. Agjentët përfundojnë duke bërë përputhje modelesh në nivel lokal në vend që të lundrojnë me qëllim.
• Kalbet menjëherë. Një manual monolitik shndërrohet në një varrezë rregullash të vjetëruara. Agjentët nuk mund të dallojnë se çfarë është ende e vërtetë, njerëzit ndalojnë së mirëmbajturi atë dhe skedari në heshtje bëhet një burim tërheqës i problemeve.
• Është e vështirë për t'u verifikuar. Një blob i vetëm nuk i përshtatet kontrolleve mekanike (coverage, freshness, ownership, cross-links), kështu që devijimi është i pashmangshëm.

Pra, në vend që ta trajtojmë AGENTS.md si enciklopedinë, e trajtojmë si tabela e përmbajtjes.

Baza e njohurive e depozitës ndodhet në një direktori të strukturuar docs/ që trajtohet si sistemi i regjistrimit. Një AGENTS.md i shkurtër (rreth 100 rreshta) futet në kontekst dhe shërben kryesisht si një hartë, me tregues drejt burimeve më të thella të së vërtetës diku tjetër.

Dokumentacioni i dizajnit është kataloguar dhe indeksohet, duke përfshirë statusin e verifikimit dhe një grup bindjesh thelbësore që përcaktojnë parimet e funksionimit të orientuara drejt agjentit. Dokumentacioni i arkitekturës⁠(hapet në një dritare të re) ofron një hartë të nivelit të lartë të domeneve dhe shtresëzimit të paketave. Një dokument cilësie vlerëson çdo domen produkti dhe shtresë arkitekturore, duke ndjekur boshllëqet me kalimin e kohës.

Planet trajtohen si artefakte të klasit të parë. Planet e përkohshme të lehta përdoren për ndryshime të vogla, ndërsa puna komplekse përfshihet në planet e ekzekutimit⁠(hapet në një dritare të re) me regjistra të progresit dhe vendimeve që ruhen në depo. Planet aktive, planet e përfunduara dhe borxhi teknik i njohur janë të gjitha të versionuara dhe të bashkëvendosura, duke u lejuar agjentëve të operojnë pa u mbështetur në kontekst të jashtëm.

Kjo mundëson zbulim progresiv: agjentët fillojnë me një pikë hyrëse të vogël dhe të qëndrueshme dhe mësohen se ku të shikojnë më pas, në vend që të mbingarkohen që në fillim.

Ne e zbatojmë këtë në mënyrë mekanike. Linterët e dedikuar dhe detyrat CI verifikojnë që baza e njohurive është e përditësuar, e ndërlidhur dhe e strukturuar saktësisht. Një agjent i përsëritur “doc-gardening” skanon për dokumentacion të vjetruar ose të tejkaluar që nuk pasqyron sjelljen reale të kodit dhe hap pull request për rregullime.

Ndërsa baza e kodit evoluonte, korniza e Codex për vendimet e dizajnit duhej të evoluonte gjithashtu.

Meqenëse depoja është tërësisht e gjeneruar nga agjentët, ajo është optimizuar fillimisht për Codex lexueshmërinë. Në të njëjtën mënyrë si ekipet synojnë të përmirësojnë navigueshmërinë e kodit të tyre për punësimet e reja inxhinierike, qëllimi i inxhinierëve tanë njerëzorë ishte të bënin të mundur që një agjent të arsyetojë për të gjithë domenin e biznesit drejtpërdrejt nga vetë depoja.

Nga këndvështrimi i agjentit, çdo gjë që nuk mund të aksesohet në kontekst gjatë ekzekutimit, në mënyrë efektive nuk ekziston. Njohuritë që ndodhen në Google Docs, në biseda ose në mendjet e njerëzve nuk janë të aksesueshme për sistemin. Artefaktet e versionuara lokale në depo (p.sh., kod, markdown, skema, plane të ekzekutueshme) janë gjithçka që mund të shohë.

Mësuam se duhej të shtynim gjithnjë e më shumë kontekst në depo me kalimin e kohës. Ajo bisedë në Slack që e bashkoi ekipin për një model arkitekturor? Nëse nuk është i zbulueshëm për agjentin, është i palexueshëm në të njëjtën mënyrë siç do të ishte i panjohur për një të sapopunësuar që bashkohet tre muaj më vonë.

T’i japësh Codex më shumë kontekst do të thotë të organizosh dhe të shfaqësh informacionin e duhur në mënyrë që agjenti të mund të arsyetojë mbi të, në vend që ta mbingarkosh me udhëzime të rastësishme. Në të njëjtën mënyrë siç do të integroje një shok të ri skuadre mbi parimet e produktit, normat e inxhinierisë dhe kulturën e ekipit (përfshirë preferencat për emoji), dhënia e këtij informacioni agjentit çon në një prodhim më të përputhur.

Ky inkuadrim sqaroi shumë dilema. Ne favorizuam varësitë dhe abstraksionet që mund të përvetësoheshin plotësisht dhe të arsyetoheshin brenda depozitës. Teknologjitë që shpesh përshkruhen si “të mërzitshme” priren të jenë më të lehta për agjentët për t'u model për shkak të kompozueshmërisë, qëndrueshmërisë së API-së dhe përfaqësimit në setin e trajnimit. Në disa raste, ishte më e lirë që agjent të riimplementonte nëngrupe të funksionalitetit sesa të anashkalonte sjelljen e paqartë të bibliotekave publike në rrjedhën e sipërme. Për shembull, në vend që të përdornim një paketë të përgjithshme në stilin p-limit, ne krijuam ndihmësin tonë për hartë me përputhshmëri: është i integruar ngushtë me instrumentimin tonë OpenTelemetry, ka mbulim testesh 100% dhe sillet saktësisht ashtu siç e pret runtime-i ynë.

Duke sjellë më shumë nga sistemi në një formë që agjenti mund ta inspektojë, verifikojë dhe modifikojë drejtpërdrejt rrit ndikimin — jo vetëm për Codex, por edhe për agjentë të tjerë (p.sh. Aardvark) që po punojnë gjithashtu në bazën e kodit.

Vetëm dokumentacioni nuk e mban një bazë kodi tërësisht të gjeneruar nga agjentët koherente. Duke zbatuar invariante, jo duke mikromenaxhuar implementimet, u lejojmë agjentëve të dërgojnë shpejt pa dëmtuar themelin. Për shembull, ne kërkojmë që Codex të analizojë format e të dhënave në kufi⁠(hapet në një dritare të re), por nuk jemi të përshkruar për mënyrën se si ndodh kjo (modeli duket se e pëlqen Zod, por ne nuk e specifikuam atë bibliotekë të veçantë).

Agjentët janë më efektivë në mjedise me kufij të rreptë dhe strukturë të parashikueshme⁠(hapet në një dritare të re), prandaj e ndërtuam aplikacionin mbi një model arkitekturor të ngurtë. Çdo fushë biznesi është i ndarë në një grup të caktuar shtresash, me drejtime varësie të kontrolluara rreptësisht dhe një grup të kufizuar skajesh të lejuara. Këto kufizime zbatohen mekanikisht përmes linterëve të personalizuar (të gjeneruar nga Codex, sigurisht!) dhe testeve strukturore.

Diagrami më poshtë tregon rregullin: brenda secilit fushë biznesi (p.sh. Cilësimet e aplikacionit), kodi mund të varet vetëm “përpara” përmes një grupi të fiksuar shtresash (Types → Config → Repo → Service → Runtime → UI). Shqetësimet ndërprerëse (auth, connectors, telemetry, feature flags) hyjnë përmes një ndërfaqeje të vetme të qartë: Providers. Çdo gjë tjetër është e ndaluar dhe zbatohet në mënyrë mekanike.

Ky është lloji i arkitekturës që zakonisht e shtyn derisa të kesh qindra inxhinierë. Me agjentët e kodimit, është një parakusht i hershëm: kufizimet janë ato që lejojnë shpejtësi pa degradim ose devijim arkitekturor.

Në praktikë, ne i zbatojmë këto rregulla me lintera të personalizuar dhe teste strukturore, plus një grup të vogël “taste invariants”. Për shembull, ne zbatojmë në mënyrë statike regjistrimin e strukturuar, konventat e emërtimit për skemat dhe llojet, kufijtë e madhësisë së skedarit dhe kërkesat e besueshmërisë specifike për platformën me lints të personalizuara. Meqenëse lints janë të personalizuara, ne shkruajmë mesazhet e gabimit për të futur udhëzime për korrigjim në kontekstin e agjentit.

Në një fluks pune ku njeriu është i pari, këto rregulla mund të duken pedante ose kufizuese. Me agjentë, ata bëhen shumëzues: pasi të kodohen, aplikohen menjëherë kudo.

Në të njëjtën kohë, jemi të qartë për vendet ku kufizimet kanë rëndësi dhe ku nuk kanë. Kjo i ngjan drejtimit të një organizate të madhe platforme inxhinierike: zbato kufijtë në mënyrë qendrore, lejo autonominë në nivel lokal. Ti kujdesesh shumë për kufijtë, saktësinë dhe riprodhueshmërinë. Brenda atyre kufijve, ju lejoni ekipeve — ose agjentëve — liri të konsiderueshme në mënyrën se si shprehen zgjidhjet.

Kodi që rezulton nuk përputhet gjithmonë me preferencat stilistike të njerëzve, dhe kjo është në rregull. Për sa kohë që rezultati është i saktë, i mirëmbajtshëm dhe i lexueshëm për ekzekutimet e ardhshme të agjentëve, ai e përmbush kërkesën.

Shija njerëzore kthehet te sistemi vazhdimisht. Komentet e rishikimit, pull request të rifaktorizuara dhe gabimet e dukshme për përdoruesin kapen si përditësime të dokumentacionit ose kodohen drejtpërdrejt në mjetet. Kur dokumentacioni nuk është i mjaftueshëm, ne e promovojmë rregullin në kod

Ndërsa kapacitet përpunimi i Codex-it u rrit, shumë norma konvencionale inxhinierike u bënë kundërproduktive.

Depoja funksionon me porta bashkimi me bllokim minimal. Pull request janë të përkohshme. Testet e paqëndrueshme shpesh zgjidhen me ekzekutime pasuese, në vend që të ndalohet përparimi pafundësisht. Në një sistem ku kapaciteti i përpunimit të agjentëve tejkalon ndjeshëm vëmendjen njerëzore, korrigjimet janë të lira, ndërsa pritja është e kushtueshme.

Kjo do të ishte e papërgjegjshme në një mjedis me kapacitet përpunimi të ulët. Këtu, shpesh është zgjedhja e duhur.

Kur themi se baza e kodit është gjeneruar nga agjentët e Codex, nënkuptojmë çdo gjë në të.

Agjentët krijojnë:

• Kodi i produktit dhe testet
• Konfigurimi i CI dhe mjetet e qarkullimit
• Mjetet e brendshme të zhvilluesve
• Historia e dokumentacionit dhe dizajnit
• Sistemet e testimit të vlerësimit
• Komente dhe përgjigje të rishikimit
• Skripte që menaxhojnë vetë depon
• Skedarët e përkufizimeve të pultit të prodhimit

Njerëzit gjithmonë mbeten në qark, por punojnë në një nivel tjetër abstraksioni nga sa ishim mësuar. Ne i japim përparësi punës, shndërrojmë komentet e përdoruesve në kritere pranimi dhe verifikojmë rezultatet. Kur agjenti has vështirësi, ne e trajtojmë si një sinjal: identifikojmë çfarë mungon — mjete, masa mbrojtëse, dokumentacion — dhe e rikthejmë në depo, gjithmonë duke e lejuar Codex-in të shkruajë vetë rregullimin.

Agjentët përdorin mjetet tona standarde të zhvillimit drejtpërdrejt. Ata tërheqin komentet e shqyrtimit, përgjigjen drejtpërdrejt, shtyjnë përditësime dhe shpesh i shkrijnë dhe i bashkojnë pull request e tyre.

Ndërsa më shumë nga cikli i zhvillimit u kodua drejtpërdrejt në sistem — testimi, validimi, shqyrtimi, trajtimi i komenteve dhe rikuperimi —depoja së fundmi kaloi një prag të rëndësishëm ku Codex mund të drejtojë një veçori të re nga fillimi në fund.

Me një kërkesë të vetme, agjenti tani mund të:

• Verifikojë gjendjen aktuale të bazës së kodit
• Riprodhojë një gabim të raportuar
• Regjistrojë një video që demonstron dështimin
• Zbatojë një korrigjim
• Verifikojë rregullimin duke drejtuar aplikacionin
• Regjistrojë një video të dytë që demonstron zgjidhjen
• Hapë një pull request
• Përgjigjet ndaj përshtypjeve nga agjentë dhe njerëz
• Zbulojë dhe rregullojë dështimet e ndërtimit
• Përshkallëzojë te një njeri vetëm kur kërkohet gjykim
• Bashkojë ndryshimin

Kjo sjellje varet shumë nga struktura specifike dhe mjetet e kësaj depoje dhe nuk duhet të supozohet se do të përgjithësohet pa një investim të ngjashëm — të paktën, jo ende.

Autonomia e plotë e agjentit gjithashtu paraqet probleme të reja. Codex riprodhon modele që tashmë ekzistojnë në depo — madje edhe ato të pabarabarta ose nënoptimizuara. Me kalimin e kohës, kjo në mënyrë të pashmangshme çon në devijim.

Fillimisht, njerëzit e trajtonin këtë manualisht. Ekipi ynë më parë shpenzonte çdo të premte (20% të javës) duke pastruar “llumin e AI-së.” Siç pritej, kjo nuk u përhap.

Në vend të kësaj, filluam të kodonim atë që e quajmë “parime të arta” drejtpërdrejt në depo dhe ndërtuam një proces pastrimi të përsëritur. Këto parime janë rregulla mekanike dhe të njëanshme që e mbajnë bazën e kodit të lexueshme dhe të qëndrueshme për ekzekutimet e ardhshme të agjentëve. Për shembull: (1) ne preferojmë paketa të përbashkëta utilitare në vend të ndihmësve të ndërtuar me dorë për të mbajtur variantet e brendshme të centralizuara, dhe (2) ne nuk i hetojmë të dhënat “në stilin YOLO” — ne vërtetojmë kufijtë ose mbështetemi te SDK e tipizuara që agjent të mos ndërtojë pa dashje mbi forma të hamendësuara. Me një ritëm të rregullt, kemi një grup detyrash në sfond të Codex që skanojnë për devijime, përditësojnë notat e cilësisë dhe hapin pull request të synuara për rifaktorizim. Shumica e këtyre mund të shqyrtohen për më pak se një minutë dhe të bashkohen automatikisht.

Kjo funksionon si grumbullimi i mbeturinave. Borxhi teknik është si një hua me interes të lartë: pothuajse gjithmonë është më mirë ta shlyesh vazhdimisht me hapa të vegjël sesa ta lësh të grumbullohet dhe ta trajtosh me shpërthime të dhimbshme. Shija njerëzore kapet një herë, pastaj zbatohet vazhdimisht në çdo rresht të kodit. Kjo na lejon gjithashtu të kapim dhe zgjidhim modelet e këqija çdo ditë, në vend që t'i lëmë të përhapen në bazën e kodit për ditë ose javë.

Kjo strategji deri tani ka funksionuar mirë deri në qarkullimin e brendshëm dhe adoptimin te OpenAI. Ndërtimi i një produkti të vërtetë për përdorues të vërtetë na ndihmoi të ankoronim investimet tona në realitet dhe të na drejtonte drejt mirëmbajtjes afatgjatë.

Ajo që ende nuk e dimë është se si koherenca arkitekturore zhvillohet me kalimin e viteve në një sistem tërësisht të krijuar nga agjentët. Ne ende po mësojmë se ku gjykimi njerëzor sjell ndikimin më të madh dhe si ta kodifikojmë atë gjykim që të përforcohet. Ne gjithashtu nuk e dimë se si do të zhvillohet ky sistem ndërsa modelet vazhdojnë të përmirësohen me kalimin e kohës.

Ajo që është bërë e qartë: ndërtimi i softuerit ende kërkon disiplinë, por disiplina shfaqet më shumë te skelat sesa te kodi. Mjetet, abstraksionet dhe ciklet e përshtypjeve që e mbajnë bazën e kodit koherente po bëhen gjithnjë e më të rëndësishme.

Sfidat tona më të vështira tani përqendrohen në projektimin e mjediseve, cikleve të reagimit dhe sistemeve të kontrollit që ndihmojnë agjentët të arrijnë qëllimin tonë: të ndërtojnë dhe të mirëmbajnë softuer kompleks dhe të besueshëm në shkallë të gjerë.

Ndërsa agjentë si Codex marrin përsipër pjesë më të mëdha të ciklit jetësor të softuerit, këto pyetje do të kenë edhe më shumë rëndësi. Shpresojmë që ndarja e disa mësimeve të hershme të të ndihmojë të arsyetosh se ku të investosh përpjekjen tënde, në mënyrë që ti mund thjesht të ndërtosh gjëra.