Uhandisi wa kuunganisha: kutumia Codex katika ulimwengu wa wakala

Katika kipindi cha miezi mitano iliyopita, timu yetu imekuwa ikiendesha jaribio: kuunda na kusafirisha toleo la beta la ndani la bidhaa ya programu yenye mistari 0 ya msimbo ilioandikwa kwa mikono.

Bidhaa ina watumiaji wa ndani wa kila siku na wachunguzi wa nje wa alpha. Husafirishwa, hupelekwa, huvunjika, na kurekebishwa. Kilicho tofauti ni kwamba kila mstari wa msimbo—mantiki ya programu, majaribio, usanidi wa CI, nyaraka, ufuatiliaji, na zana za ndani—zimeandikwa na Codex. Tunakadiria kwamba tuliunda hii kwa takriban 1/10 ya muda ambao ungetumika kuandika msimbo kwa mkono.

Binadamu huongoza. Wakala hutekeleza.

Tulichagua kizuizi hiki kimakusudi ili tuunde kile kilichohitajika kuongeza kasi ya uhandisi kwa kiwango kikubwa sana. Tulikuwa na wiki kadhaa kusafirisha kile ambacho hatimaye kiligeuka kuwa mistari milioni moja ya misimbo. Ili kufanya hivyo, tulihitaji kuelewa ni nini hubadilika wakati kazi ya msingi ya timu ya uhandisi wa programu si kuandika tena msimbo, bali kubuni mazingira, kubainisha nia, na kuunda mizunguko ya mrejesho inayowawezesha mawakala wa Codex kufanya kazi ya kuaminika.

Chapisho hili linahusu tulichojifunza kwa kuunda bidhaa mpya kabisa na timu ya mawakala—kilichovunjika, kilichoongezeka, na jinsi ya kuongeza rasilimali yetu moja adimu kweli: muda na umakini wa binadamu.

Marekebisho ya kwanza kwenye uhifadhi mtupu yalifika mwishoni mwa Agosti 2025.

Kiunzi cha awali—muundo wa uhifadhi, usanidi wa CI, sheria za uundaji, usanidi wa msimamizi wa vifurushi, na mfumo wa programu—kiliundwa na Codex CLI kwa kutumia GPT‑5, kikiongozwa na seti ndogo ya violezo vilivyopo. Hata faili ya awali ya AGENTS.md inayowaelekeza mawakala jinsi ya kufanya kazi katika uhifadhi iliandikwa na Codex.

Hakukuwa na msimbo uliokuwa umeandikwa na binadamu awali wa kuuweka mfumo msingi. Tangu mwanzo, uhifadhi uliundwa na wakala.

Miezi mitano baadaye, uhifadhi una takriban mistari milioni moja ya misimbo katika mantiki ya programu, miundombinu, zana, nyaraka, na huduma za ndani za wasanidi programu. Katika kipindi hicho, takriban pull requests 1,500 zimefunguliwa na kuunganishwa na timu ndogo ya wahandisi watatu tu wanaoendesha Codex. Hii inatafsiriwa kuwa wastani wa utendaji wa 3.5 PRs kwa kila mhandisi kwa siku, na cha kushangaza utendaji umeongezeka kadri timu ilivyokua hadi sasa kuwa na wahandisi saba. Muhimu zaidi, haya hayakuwa matokeo kwa ajili ya matokeo tu: bidhaa imetumiwa na mamia ya watumiaji wa ndani, ikijumuisha watumiaji hodari wa ndani wa kila siku.

Katika mchakato mzima wa maendeleo, wanadamu hawakuchangia moja kwa moja msimbo wowote. Hii ikawa falsafa ya msingi kwa timu: hakuna msimbo uliotungwa kwa mkono.

Ukosefu wa usimbaji wa kibinadamu wa vitendo ulianzisha aina tofauti ya kazi ya uhandisi, inayolenga mifumo, miundo, na utumiaji wa rasilimali.

Maendeleo ya awali yalikuwa ya polepole kuliko tulivyotarajia, si kwa sababu Codex haikuwa na uwezo, bali kwa sababu mazingira hayakubainishwa vya kutosha. Wakala alikosa zana, dhana, na muundo wa ndani unaohitajika ili kufanya maendeleo kuelekea malengo ya juu. Kazi kuu ya timu yetu ya uhandisi ikawa kuwawezesha mawakala kufanya kazi yenye manufaa.

Kwa vitendo, hii ilimaanisha kufanya kazi kwa mtindo wa kina-kwanza: kugawanya malengo makubwa kuwa vitalu vidogo vya ujenzi (muundo, msimbo, ukaguzi, jaribi, nk), hivyo kumshawishi wakala kuunda vitalu hivyo, na kuvitumia kufungua majukumu changamani zaidi. Wakati kitu kiliposhindikana, suluhisho kamwe halikuwa “jaribu kwa bidii zaidi.” Kwa sababu njia pekee ya kufanya maendeleo ilikuwa kuifanya Codex ifanye kazi, wahandisi wa binadamu kila mara waliingia kwenye kazi na kuuliza: “ni uwezo gani unakosekana, na tunawezaje kuufanya uwe unaosomeka na unaoweza kutekelezwa kwa ajili ya wakala?”

Binadamu huingiliana na mfumo kabisa kupitia madokezo: mhandisi huelezea kazi, huendesha wakala, na huiruhusu kufungua pull request. Ili kukamilisha PR, tunaelekeza Codex kukagua mabadiliko yake mwenyewe ndani ya eneo la ndani, kuomba ukaguzi wa ziada wa wakala maalum ndani na kwenye wingu, kujibu maoni yoyote yaliyotolewa na binadamu au wakala, na kurudia katika mzunguko hadi wakaguzi wote wa wakala waridhike (kimsingi huu ni Mzunguko wa Ralph Wiggum⁠(fungua katika dirisha jipya)). Codex hutumia zana zetu za kawaida za maendeleo moja kwa moja (gh, hati za ndani, na ujuzi uliowekwa ndani ya uhifadhi) kukusanya muktadha bila wanadamu kunakili na kubandika kwenye CLI.

Binadamu wanaweza kukagua pull request, lakini hawalazimiki kufanya hivyo. Baada ya muda, tumesukuma karibu juhudi zote za ukaguzi kuelekea kutendwa wakala kwa wakala.

Kadiri utendaji wa msimbo ulivyoongezeka, kikwazo chetu kikawa uwezo wa ukaguzi wa ubora wa binadamu. Kwa sababu kikwazo kisichobadilika kimekuwa ni muda na umakini wa binadamu, tumefanya kazi kuongeza uwezo zaidi kwa wakala kwa kufanya vitu kama UI ya programu, kumbukumbu, na vipimo vya programu vyenyewe visomeke moja kwa moja kwa Codex.

Kwa mfano, tulifanya programu iweze kuwashwa kwa kila git worktree, ili Codex iweze kuzindua na kuendesha tukio moja kwa kila mabadiliko. Pia tuliunganisha Itifaki ya Chrome DevTools kwenye mazingira ya utekelezaji ya wakala na kuunda ujuzi wa kufanya kazi na picha za DOM, picha za skrini, na urambazaji. Hii iliwezesha Codex kuzalisha tena hitilafu, kuthibitisha marekebisho, na kufikiria moja kwa moja kuhusu tabia ya UI.

Tulifanya vivyo hivyo kwa zana za ufuatiliaji. Kumbukumbu, vipimo, na nyayo zinafichuliwa kwa Codex kupitia safu ya ndani ya uangalizi inayokuwa ya muda kwa kila worktree. Codex hufanya kazi kwenye toleo lililotengwa kikamilifu la programu hiyo—ikiwemo kumbukumbu na vipimo vyake, ambavyo huondolewa mara tu kazi hiyo inapokamilika. Mawakala wanaweza kuuliza kumbukumbu kwa LogQL na vipimo kwa PromQL. Muktadha huu unapopatikana, madokezo kama vile “hakikisha uanzishaji wa huduma unakamilika ndani ya 800ms” au “hakuna muda katika safari hizi nne muhimu za mtumiaji inayozidi sekunde mbili” huwa rahisi kushughulikia.

Mara kwa mara tunaona uendeshaji mmoja wa Codex ukifanya kazi kwenye kazi moja kwa zaidi ya saa sita (mara nyingi wakati wanadamu wamelala).

Usimamizi wa muktadha ni mojawapo ya changamoto kubwa zaidi katika kufanya mawakala kuwa na ufanisi katika kazi kubwa na changamani. Moja ya masomo ya awali tuliyojifunza lilikuwa rahisi: ipe Codex ramani, si mwongozo wa kurasa 1,000.

Tulijaribu “AGENTS.md⁠(fungua katika dirisha jipya) moja kubwa” mbinu. Ilishindwa kwa njia zilizotarajiwa:

• Muktadha ni rasilimali adimu. Faili kubwa la maagizo linasongamana na kazi, msimbo, na hati husika—hivyo wakala hukosa vikwazo muhimu au huanza kuboresha kwa visivyo sahihi.
• Mwongozo mwingi unakuwa kutokuwa mwongozo. Wakati kila kitu ni “muhimu,” hakuna kinachokuwa muhimu. Mawakala huishia kulinganisha mifumo kwa ndani badala ya kusafiri kwa makusudi.
• uharibika papo hapo. Mwongozo wa monolithic unageuka kuwa kaburi la kanuni zilizopitwa na wakati. Mawakala hawawezi kutambua kile ambacho bado ni kweli, wanadamu wanaacha kukidumisha, na faili kimya kimya inakuwa kero linalovutia.
• Ni vigumu kuthibitisha. Kipande kimoja hakifai kwa ukaguzi wa kiufundi (upanuzi, uchangamfu, umiliki, viungo mtambuka), kwa hivyo mkengeuko ni jambo lisiloepukika.

Kwa hivyo, badala ya kuchukulia AGENTS.md kama ensaiklopidia, tunachukulia kama orodha ya yaliyomo.

Msingi wa maarifa wa uhifadhi upo katika saraka iliyo na muundo wa docs/ inayochukuliwa kama mfumo wa kumbukumbu. AGENTS.md fupi (takriban mistari 100) huingizwa katika muktadha na hutumika kimsingi kama ramani, ikiwa na viashiria vya vyanzo vya kina zaidi vya ukweli mahali pengine.

Nyaraka za usanifu zimeorodheshwa na kuwekewa faharasa, zikijumuisha hali ya uthibitishaji na seti ya imani za msingi zinazofafanua kanuni za uendeshaji za wakala-kwanza. Nyaraka za usanifu⁠(fungua katika dirisha jipya) zinatoa ramani ya kiwango cha juu ya vikoa na utabakaji wa vifurushi. Hati ya ubora hupima kila kikoa cha bidhaa na safu ya usanifu, ikifuatilia mapengo kwa muda.

Mipango inachukuliwa kama vitu vya daraja la kwanza. Mipango nyepesi ya muda mfupi hutumika kwa mabadiliko madogo, ilhali kazi changamano hunaswa katika mipango ya utekelezaji⁠(fungua katika dirisha jipya) yenye kumbukumbu za maendeleo na maamuzi ambazo huingizwa kwenye uhifadhi. Mipango inayoendelea, mipango iliyokamilika, na deni la kiufundi linalojulikana yote yana matoleo na yamewekwa pamoja, hivyo kuruhusu mawakala kufanya kazi bila kutegemea muktadha wa nje.

Hii huwezesha ufichuzi wa hatua kwa hatua: mawakala huanza na sehemu ndogo, thabiti ya kuingilia na hufundishwa wapi pa kuangalia baadaye, badala ya kuzidiwa mwanzoni.

Tunatekeleza hili kwa njia ya kiufundi. Kazi za wataalamu wa CI na CI zinathibitisha kwamba msingi wa maarifa umesasishwa, umeunganishwa kwa njia mbalimbali, na umepangwa ipasavyo. Wakala wa mara kwa mara wa “doc-gardening” huchanganua nyaraka zilizopitwa na wakati au zilizopitwa na matumizi ambazo haziakisi tabia halisi ya msimbo na hufungua pull request za kurekebisha.

Kadri msingi wa msimbo ulivyokua, ndivyo mfumo wa Codex wa maamuzi ya muundo ulipaswa kubadilika pia.

Kwa sababu uhifadhi imeundwa kikamilifu na wakala, imeboreshwa kwanza kwa usomaji wa Codex. Kwa njia ile ile timu zinalenga kuboresha urambazaji wa msimbo wao kwa waajiriwa wapya wa uhandisi, lengo la wahandisi wetu wa kibinadamu lilikuwa kufanya iwezekane kwa wakala kutafakari kuhusu eneo zima la biashara moja kwa moja kutoka kwenye hifadhi yenyewe.

Kutoka kwa mtazamo wa wakala, chochote ambacho hakiwezi kufikiwa ndani ya muktadha wakati wa kuendesha kwa ufanisi kimsingi hakipo. Maarifa yaliyo katika Google Docs, nyuzi za mazungumzo, au vichwani mwa watu hayapatikani kwa mfumo. Vifaa vya ndani vya uhifadhi, vilivyowekwa toleo (mfano, msimbo, alama, vielezo, mipango inayoweza kutekelezwa) ndivyo tu inavyoweza kuona.

Tuligundua kwamba tulihitaji kuweka muktadha zaidi na zaidi kwenye hifadhi kwa muda. Je, majadiliano hayo ya Slack yaliweka timu katika mwelekeo mmoja kuhusu muundo wa usanifu? Ikiwa haiwezi kugunduliwa na wakala, basi haiwezi kusomeka kwa njia sawa na ambayo ingekuwa haijulikani kwa mfanyakazi mpya anayejiunga miezi mitatu baadaye.

Kuipa Codex muktadha zaidi kunamaanisha kupanga na kuweka wazi taarifa sahihi ili wakala aweze kutoa hoja kuihusu, badala ya kuilemea kwa maagizo ya papo hapo yasiyo na mpangilio. Kwa njia ile ile ambayo ungemwongoza mwenzako mpya wa timu kuhusu kanuni za bidhaa, viwango vya uhandisi, na utamaduni wa timu (ikiwemo mapendeleo ya emoji), kumpa wakala taarifa hii husababisha matokeo yanayolingana zaidi.

Uundaji huu wa fremu ulifafanua mabadilishano mengi. Tulipendelea utegemezi na dhana ambazo zingeweza kuingizwa kikamilifu na kufikiriwa ndani ya hifadhi. Teknolojia ambazo mara nyingi hufafanuliwa kama “zinazochosha” huwa rahisi zaidi kwa mawakala kutengeneza miundo kutokana na uwezo wa kuunganishwa, uthabiti wa API, na uwakilishi katika seti ya mafunzo. Katika baadhi ya matukio, ilikuwa nafuu zaidi kwa wakala kutekeleza upya sehemu ndogo za utendaji kuliko kushughulikia tabia isiyoeleweka ya maktaba za umma. Kwa mfano, badala ya kuingiza kifurushi cha jumla cha mtindo wa p-limit, tulitekeleza kisaidizi chetu wenyewe cha ramani-yenye-ushirikiano: kimeunganishwa kwa karibu na uwekaji ala wetu wa OpenTelemetry, una kiwango cha majaribio cha 100%, na hufanya kazi hasa kwa njia ambayo mazingira yetu ya utekelezaji yanatarajia.

Kuvuta zaidi mfumo katika fomu ambayo wakala anaweza kukagua, kuthibitisha, na kurekebisha moja kwa moja huongeza ushawishi—si kwa Codex tu, bali pia kwa mawakala wengine (kwa mfano, Aardvark) ambao pia wanafanya kazi kwenye msimbo huo pia.

Nyaraka pekee hazidumishi msimbo unaozalishwa kikamilifu na wakala kuwa thabiti. Kwa kutekeleza kanuni zisizobadilika, badala ya kusimamia kwa undani utekelezaji, tunawawezesha mawakala kusafirisha haraka bila kudhoofisha msingi. Kwa mfano, tunahitaji Codex kuchanganua maumbo ya data kwenye mipaka⁠(fungua katika dirisha jipya), lakini hatuelekezi kwa lazima jinsi hilo linavyofanyika (muundo unaonekana kupenda Zod, lakini hatukubainisha maktaba hiyo mahususi).

Mawakala wana ufanisi zaidi katika mazingira yenye mipaka madhubuti na muundo unaotabirika⁠(fungua katika dirisha jipya), kwa hivyo tuliunda programu kwa kutumia muundo wa usanifu thabiti. Kila kikoa cha biashara kimegawanywa katika seti isiyobadilika ya tabaka, zenye mwelekeo wa utegemezi uliothibitishwa kwa ukali na seti ndogo ya miunganisho inayoruhusiwa. Vikwazo hivi vinatekelezwa kimitambo kupitia vizuizi maalum (zilizotengenezwa na Codex, bila shaka!) na majaribio ya kimuundo.

Mchoro ulio hapa chini unaonyesha kanuni: ndani ya kila kikoa cha biashara (mfano. Mipangilio ya Programu), msimbo unaweza kutegemea tu “mbele” kupitia seti isiyobadilika ya safu (Aina → Usanidi → Hifadhi → Huduma → Muda wa utekelezaji → UI). Masuala mtambuka (uthibitishaji, viunganishi, telemetri, bendera za vipengele) huingia kupitia kiolesura kimoja wazi: Watoa huduma. Chochote kingine hakiruhusiwi na kinatekelezwa kwa njia ya mitambo.

Huu ndio aina ya usanifu ambao kwa kawaida huahirishwa hadi utakapokuwa na mamia ya wahandisi. Kwa mawakala wa usimbaji, ni sharti la awali: vikwazo ndivyo vinavyowezesha kasi bila kudorora au kupotoka kwa usanifu.

Kwa vitendo, tunatekeleza sheria hizi kwa kutumia vizuzi maalum na majaribio ya kimuundo, pamoja na seti ndogo ya “vigezo visivyobadilika.” Kwa mfano, tunatekeleza kwa uthabiti utaratibu uleule wa kumbukumbu zilizopangwa, kanuni za uundaji majina kwa vielezo na aina, vikomo vya ukubwa wa faili, na mahitaji ya kutegemewa mahususi kwa mfumo wa kutumia viambatisho maalum. Kwa sababu viambatisho ni maalum, tunaandika ujumbe wa hitilafu ili kuingiza maagizo ya urekebishaji katika muktadha wa wakala.

Katika utaratibu wa kazi unaoweka binadamu kwanza, sheria hizi zinaweza kuonekana kuwa za kupindukia au za kuzuia. Kwa mawakala, wanakuwa vizidishi: mara tu wanapowekwa msimbo, hutumika kila mahali kwa wakati mmoja.

Wakati huohuo, tunaweka wazi mahali ambapo vikwazo ni muhimu na mahali ambapo si muhimu. Hii inafanana na kuongoza shirika kubwa la mfumo wa uhandisi: tekeleza mipaka kwa njia ya kati, kuruhusu uhuru kindani. Unajali sana kuhusu mipaka, usahihi, na uwezekano wa kurudiwa. Ndani ya mipaka hiyo, unaruhusu timu—au mawakala—uhuru mkubwa katika jinsi suluhisho zinavyoelezwa.

Msimbo unaotokana hauendani kila wakati na mapendeleo ya kimtindo ya binadamu, na hilo ni sawa. Mradi tu matokeo ni sahihi, yanaweza kudumishwa, na yanaosomeka kwa uendeshaji wa baadaye wa wakala, yanatimiza kiwango.

Vigezo vya binadamu vinarudishwa kwenye mfumo kila wakati. Maoni ya ukaguzi, pull request za urekebishaji wa msimbo, na hitilafu zinazoonekana kwa mtumiaji hunaswa kama masasisho ya nyaraka au husimbwa moja kwa moja kwenye zana. Wakati hati hazitoshelezi, tunabadilisha sheria hiyo kuwa msimbo

Kadiri utendaji wa Codex ulivyoongezeka, ndivyo kanuni nyingi za kawaida za uhandisi zikawa hazifai tena.

Uhifadhi hufanya kazi kwa vizuizi vidogo vya milango ya kuunganisha. Pull requests ni za muda mfupi. Vipimo visivyo thabiti mara nyingi hushughulikiwa kwa majaribio ya ufuatiliaji badala ya kuzuia maendeleo bila kikomo. Katika mfumo ambapo utendaji wa wakala unazidi sana umakini wa binadamu, masahihisho ni ya gharama nafuu, na kusubiri ni ghali.

Hili lingekuwa jambo lisilo la kuwajibika katika mazingira ya utendaji wa chini. Hapa, mara nyingi ni chaguo sahihi.

Tunaposema msingi wa msimbo umetengenezwa na mawakala wa Codex, tunamaanisha kila kitu katika msingi huo.

Mawakala huzalisha:

• Msimbo wa bidhaa na vipimo
• Usanidi wa CI na zana za kutolewa
• Zana za ndani za msanidi programu
• Historia ya nyaraka na muundo
• Viungnaishi vya tathmini
• Hukagua maoni na majibu
• Huandika hati zinazodhibiti uhifadhi wenyewe
• Faili za ufafanuzi wa dashibodi ya uzalishaji

Wanadamu daima hubaki katika mchakato, lakini hufanya kazi katika kiwango tofauti cha uondoaji kuliko tulivyokuwa tukifanya awali. Tunatanguliza kazi, tunatafsiri maoni ya watumiaji kuwa vigezo vya kukubalika, na kuthibitisha matokeo. Wakati wakala anapopata ugumu, tunauchukulia kama ishara: tunatambua kinachokosekana—zana, ulinzi, nyaraka—na kuirudisha kwenye uhifadhi, kila wakati kwa kufanya Codex yenyewe iandike marekebisho.

Mawakala hutumia zana zetu za kawaida za maendeleo moja kwa moja. Wanakusanya maoni ya ukaguzi, hujibu ndani ya mstari, hutuma masasisho, na mara nyingi huchanganya na kuunganisha pull request zao wenyewe.

Kadiri mzunguko zaidi wa maendeleo ulivyosimbwa moja kwa moja kwenye mfumo—upimaji, uthibitishaji, ukaguzi, ushughulikiaji wa maoni, na urejeshaji—uhifadhi hivi karibuni ulivuka kizingiti muhimu ambapo Codex inaweza kuendesha kipengele kipya kutoka mwanzo hadi mwisho.

Kwa dokezo moja, wakala sasa anaweza:

• Kuthibitisha hali ya sasa ya msimbo
• Kurudia hitilafu iliyoripotiwa
• Kurekodi video inayoonyesha kushindwa
• Kutekeleza marekebisho
• Kuthibitisha marekebisho kwa kuendesha programu
• Kurekodi video ya pili inayoonyesha azimio
• Kufungua pull request
• Kujibu maoni ya wakala na ya binadamu
• Kutambua na kurekebisha kushindwa kwa kijenzi
• Kutuma kwa binadamu tu wakati maamuzi yanahitajika
• Kuunganisha mabadiliko

Tabia hii inategemea sana muundo mahususi na zana za uhifadhi huu na haipaswi kudhaniwa kuwa inaweza kujumlishwa bila uwekezaji kama huo—angalau, bado.

Uhuru kamili wa wakala pia unaleta matatizo mapya. Codex hurudia mifumo ambayo tayari ipo katika uhifadhi—hata ile isiyo sawa au isiyo bora. Baada ya muda, hili bila shaka husababisha kupotoka.

Hapo awali, binadamu walishughulikia hili kwa mikono. Timu yetu ilikuwa ikitumia kila Ijumaa (20% ya wiki) kusafisha “uchafu wa AI.” Haishangazi, hilo halikuweza kufanikiwa.

Badala yake, tulianza kusimba kile tunachokiita “kanuni za dhahabu” moja kwa moja kwenye uhifadhi na tukaunda mchakato wa kusafisha unaorudiwa. Kanuni hizi ni sheria za kimitambo zenye maoni maalum zinazohakikisha msimbo unasomeka na kuwa thabiti kwa uendeshaji wa wakala wa baadaye. Kwa mfano: (1) tunapendelea vifurushi vya huduma vya pamoja kuliko visaidizi vilivyotengenezwa kwa mikono ili kuweka vigezo visivyobadilika vikiwa vimewekwa katikati, na (2) hatuchunguzi data “kwa mtindo wa YOLO”—tunathibitisha mipaka au tunategemea SDK zilizo na aina ili wakala asiweze kwa bahati mbaya kuunda juu ya maumbo yaliyokisiwa. Kwa mpangilio wa mara kwa mara, tuna seti ya kazi za usuli za Codex zinazochanganua mkengeuko, kusasisha viwango vya ubora, na kufungua pull request za urekebishaji wa msimbo zinazolengwa. Mengi ya haya yanaweza kukaguliwa kwa chini ya dakika moja na kuunganishwa kiotomatiki.

Hii inafanya kazi kama ukusanyaji wa taka. Deni la kiufundi ni kama mkopo wenye riba kubwa: karibu kila wakati ni bora kulilipa mfululizo kwa nyongeza ndogo ndogo kuliko kuliacha lijilimbikize na kisha kulishughulikia kwa vipindi vya maumivu. Vigezo vya binadamu vinanaswa mara moja, kisha vinatekelezwa mfululizo kwenye kila mstari wa msimbo. Hii pia inatuwezesha kubaini na kutatua mifumo mibaya kila siku, badala ya kuiacha isambae kwenye msingi wa msimbo kwa siku au wiki.

Mkakati huu hadi sasa umefanya kazi vizuri hadi kufikia uzinduzi wa ndani na upokeaji katika OpenAI. Kuunda bidhaa halisi kwa watumiaji halisi kulisaidia kuimarisha uwekezaji wetu katika uhalisia na kutuongoza kuelekea udumishaji wa muda mrefu.

Kile ambacho bado hatujui ni jinsi mshikamano wa usanifu unavyobadilika kwa miaka katika mfumo unaozalishwa kikamilifu na mawakala. Bado tunajifunza ni wapi uamuzi wa kibinadamu unaongeza nguvu zaidi na jinsi ya kuweka uamuzi huo katika mfumo wa kidijitali ili uendelee kuongezeka. Pia hatujui jinsi mfumo huu utakavyobadilika kadri miundo inavyoendelea kuwa na uwezo zaidi kwa muda.

Kilichoonekana wazi: kuunda programu bado kunahitaji nidhamu, lakini nidhamu hiyo inaonekana zaidi kwenye miundombinu ya kusaidia badala ya kwenye msimbo. Zana, dhana, na mizunguko ya maoni inayoweka msimbo ukiwa thabiti inazidi kuwa muhimu.

Changamoto zetu ngumu zaidi sasa zinahusu kubuni mazingira, mizunguko ya maoni, na mifumo ya udhibiti inayosaidia mawakala kutimiza lengo letu: kuunda na kudumisha programu changamani na za kuaminika kwa kiwango kikubwa.

Kadiri mawakala kama Codex wanavyochukua sehemu kubwa zaidi za mzunguko wa maisha wa programu, maswali haya yatakuwa muhimu zaidi. Tunatumai kwamba kushiriki baadhi ya mafunzo ya awali kutakusaidia kufikiria kuhusu mahali pa kuwekeza juhudi zako ili uweze tu kuunda vitu.