Harness-tekniikka: Codexin käyttö agenttikeskeisessä maailmassa

Viiden viime kuukauden aikana tiimimme on suorittanut kokeilun: olemme rakentaneet ja toimittaneet ohjelmistotuotteen sisäisen beta-version, jossa on 0 riviä käsin kirjoitettua koodia.

Tuotteella on sisäisiä päivittäisiä käyttäjiä ja ulkoisia alfa-testaajia. Se toimitetaan, otetaan käyttöön, hajoaa ja korjataan. Erona on, että jokainen koodirivi—sovelluslogiikka, testit, CI-konfiguraatio, dokumentaatio, havaittavuus ja sisäiset työkalut—on Codexin kirjoittama. Arvioimme, että rakensimme tämän noin kymmenesosassa siitä ajasta, jonka koodin kirjoittaminen käsin olisi vienyt.

Ihmiset ohjaavat. Agentit suorittavat tehtäviä.

Valitsimme tämän rajoituksen tarkoituksella, jotta voisimme rakentaa sen, mikä oli välttämätöntä suunnittelun nopeuden kasvattamiseksi moninkertaisesti. Meillä oli viikkoja aikaa toimittaa miljoonia koodirivejä. Jotta se onnistuisi, meidän piti ymmärtää, mikä muuttuu, kun ohjelmistosuunnittelutiimin ensisijainen tehtävä ei enää ole kirjoittaa koodia, vaan suunnitella ympäristöjä, määrittää tarkoitus ja rakentaa palautesilmukoita, joiden avulla Codex-agentit voivat tehdä luotettavaa työtä.

Tämä kirjoitus käsittelee sitä, mitä opimme luodessamme täysin uuden tuotteen agenttitiimin kanssa—mikä meni pieleen, mitä tapahtui ja miten maksimoimme ainoan todella niukan resurssimme: ihmisten ajan ja huomion.

Ensimmäinen toimitus tyhjään repositorioon tehtiin elokuun 2025 loppupuolella.

Alkuperäinen rakennelma—repositorion rakenne, CI-konfiguraatio, muotoilusäännöt, pakettienhallinnan määritys ja sovelluskehys—luotiin Codex CLI:n avulla käyttäen GPT‑5:tä, jota ohjasi pieni joukko olemassa olevia malleja. Jopa alkuperäinen AGENTS.md-tiedosto, joka ohjeistaa agentteja työskentelemään repositoriossa, oli Codexin kirjoittama.

Järjestelmän ankkuroimiseksi ei ollut olemassa ihmisen kirjoittamaa koodia. Repositorio muotoutui agentin vaikutuksesta alusta alkaen.

Viisi kuukautta myöhemmin repositoriossa on noin miljoona koodiriviä, jotka kattavat sovelluslogiikan, infrastruktuurin, työkalut, dokumentaation ja sisäiset kehittäjätyökalut. Tuona aikana on avattu ja yhdistetty noin 1 500 pull request -pyyntöä, ja Codexia on ohjannut eteenpäin pieni, vain kolmen insinöörin tiimi. Tämä tarkoittaa 3,5 PRs keskimääräistä suoritustehoa insinööriä kohden päivässä, ja yllättäen suoritusteho on kasvanut, kun tiimi on nyt kasvanut seitsemään insinööriin. Tärkeää on, ettei tämä ollut pelkästään tuotoksen vuoksi: sadat käyttäjät ovat käyttäneet tuotetta sisäisesti, mukaan lukien päivittäiset sisäiset tehokäyttäjät.

Koko kehitysprosessin aikana ihmiset eivät koskaan suoraan kirjoittaneet koodia. Tästä tuli tiimin ydinfilosofia: ei käsin kirjoitettua koodia.

Käsin tehdyn koodauksen poissaolo toi mukanaan erilaista insinöörityötä, joka keskittyi järjestelmiin, tukirakenteisiin ja hyödyntämiseen.

Alkuvaiheen edistyminen oli odotettua hitaampaa, ei siksi, että Codex ei olisi pystynyt siihen, vaan siksi, että ympäristöä ei ollut määritelty riittävästi. Agentilta puuttuivat työkalut, abstraktiot ja sisäinen rakenne, joita tarvittiin korkean tason tavoitteiden saavuttamiseen. Insinööritiimimme ensisijaiseksi tehtäväksi tuli mahdollistaa agenttien tekemä hyödyllinen työ.

Käytännössä tämä tarkoitti työskentelyä syvyyssuuntaisesti: suurempien tavoitteiden pilkkomista pienemmiksi rakennuspalikoiksi (suunnittelu, koodaus, katselmointi, testaus jne.), agentin ohjaamista rakentamaan nämä palikat ja niiden käyttämistä monimutkaisempien tehtävien ratkaisemiseen. Kun jokin meni pieleen, korjaus ei ollut lähes koskaan "yritä kovemmin". Koska ainoa tapa edetä oli saada Codex tekemään työn, ihmisinsinöörit ryhtyivät aina tehtävään ja kysyivät: "Mikä ominaisuus puuttuu, ja miten teemme siitä sekä ymmärrettävän että toimeenpantavan agentin kannalta?"

Ihmiset ovat vuorovaikutuksessa järjestelmän kanssa lähes yksinomaan kehotteiden avulla: insinööri kuvailee tehtävän, käynnistää agentin ja sallii sen avata pull request -pyynnön. Jotta PR saadaan päätökseen, ohjeistamme Codexia tarkistamaan omat muutoksensa paikallisesti, pyytämään lisätarkastuksia tietyiltä agenteilta sekä paikallisesti että pilvessä, vastaamaan ihmisten tai agenttien antamaan palautteeseen ja toistamaan prosessia, kunnes kaikki agenttitarkastajat ovat tyytyväisiä (käytännössä tämä on Ralph Wiggum -silmukka⁠(avautuu uudessa ikkunassa)). Codex käyttää suoraan vakiokehitystyökalujamme (gh, paikalliset skriptit ja repositorioon upotetut taidot) kontekstin keräämiseen ilman, että ihmisten tarvitsee kopioida ja liittää sitä CLI:hen.

Ihmiset voivat tarkistaa pull request -pyynnöt, mutta se ei ole pakollista. Ajan myötä olemme siirtäneet lähes kaiken tarkistustyön agenttien kesken hoidettavaksi.

Kun koodin suoritusteho kasvoi, pullonkaulaksi muodostui ihmisten laadunvarmistuskapasiteetti. Koska ihmisten aika ja huomio on ollut kiinteä rajoite, olemme pyrkineet lisäämään agentin ominaisuuksia tekemällä esimerkiksi sovelluksen käyttöliittymästä, lokeista ja sovellusmittareista suoraan Codexille luettavia.

Teimme esimerkiksi sovelluksesta käynnistettävän git worktreen mukaan, jotta Codex voisi käynnistää ja hallita yhtä instanssia muutosta kohden. Liitimme myös Chrome DevTools Protocolin agentin ajonaikaiseen ympäristöön ja loimme toimintoja DOM-tilannekuvien, kuvakaappausten ja navigoinnin käsittelyyn. Näin Codex pystyi jäljentämään virheitä, vahvistamaan korjauksia ja päättelemään suoraan käyttöliittymän käyttäytymisestä.

Teimme saman havainnointityökalujen suhteen. Lokit, mittarit ja jäljet ovat Codexin käytettävissä paikallisen havaittavuuspinon kautta, joka on tilapäinen kullekin työpuulle. Codex työskentelee täysin eristetyssä sovellusversiossa, mukaan lukien sen lokit ja mittarit, jotka puretaan, kun tehtävä on valmis. Agentit voivat tehdä lokikyselyjä LogQL:llä ja mittareita PromQL:llä. Kun tämä konteksti on käytettävissä, kehotteet kuten "varmista, että palvelun käynnistys valmistuu alle 800 ms" tai "mikään ajanjakso näissä neljässä kriittisessä käyttäjämatkassa ei ylitä kahta sekuntia" muuttuvat toteuttamiskelpoisiksi.

Yksittäiset Codex-ajot työskentelevät yhden tehtävän parissa säännöllisesti yli kuusi tuntia (usein samalla kun ihmiset nukkuvat).

Kontekstin hallinta on yksi suurimmista haasteista, kun halutaan tehdä agenteista tehokkaita suurissa ja monimutkaisissa tehtävissä. Yksi varhaisimmista kokemuksistamme oli yksinkertainen: anna Codexille kartta, älä tuhatsivuista käyttöohjekirjaa.

Kokeilimme "yhtä suurta AGENTS.md⁠(avautuu uudessa ikkunassa)" -lähestymistapaa. Se epäonnistui ennustettavasti:

• Konteksti on rajallinen resurssi. Jättimäinen ohjetiedosto vie tilaa tehtävältä, koodilta ja olennaisilta dokumenteilta—joten agentti joko ohittaa keskeiset rajoitteet tai alkaa optimoida vääriä.
• Liiallinen ohjaus muuttuu ohjaamattomuudeksi. Kun kaikki on "tärkeää", mikään ei ole tärkeää. Agentit päätyvät tunnistamaan kuvioita paikallisesti sen sijaan, että navigoisivat tarkoituksella.
• Se menee pilalle välittömästi. Monoliittinen käsikirja muuttuu vanhentuneiden sääntöjen hautausmaaksi. Agentit eivät voi tietää, mikä on edelleen totta, ihmiset lakkaavat ylläpitämästä sitä, ja tiedostosta tulee hiljalleen houkutteleva haitta.
• Vahvistaminen on vaikeaa. Yksi ainoa blob ei sovellu mekaanisiin tarkistuksiin (kattavuus, tuoreus, omistajuus, ristiinlinkitykset), joten ajautuminen on väistämätöntä.

Joten sen sijaan, että käsittelemme AGENTS.md-tiedostoa tietosanakirjana, käsittelemme sitä sisällysluettelona.

Repositorion tietopohja sijaitsee jäsennellyssä docs/ -hakemistossa, jota pidetään järjestelmän ensisijaisena arkistointijärjestelmänä. Lyhyt AGENTS.md (noin 100 riviä) lisätään kontekstiin ja toimii ensisijaisesti karttana, jossa on viittauksia syvällisempiin totuuden lähteisiin muualla.

Suunnitteludokumentaatio luetteloidaan ja indeksoidaan, mukaan lukien varmennuksen tila ja joukko keskeisiä periaatteita, jotka määrittävät agentti ensin -toimintaperiaatteet. Arkkitehtuurin dokumentaatio⁠(avautuu uudessa ikkunassa) tarjoaa yleiskatsauksen toimialueista ja pakettikerrostuksesta. Laatuasiakirja arvioi kunkin tuotealueen ja arkkitehtuurikerroksen, ja seuraa puutteita ajan kuluessa.

Suunnitelmia käsitellään ensiluokkaisina artefakteina. Lyhytikäisiä kevyitä suunnitelmia käytetään pieniin muutoksiin, kun taas monimutkainen työ tallennetaan toteutussuunnitelmiin⁠(avautuu uudessa ikkunassa), joissa on edistymis- ja päätöslokit, jotka kirjataan repositorioon. Aktiiviset suunnitelmat, toteutetut suunnitelmat ja tunnettu tekninen velka ovat kaikki versioituja ja sijoitettu samaan paikkaan, jolloin agentit voivat toimia ilman ulkoista kontekstia.

Tämä mahdollistaa asteittaisen julkistamisen: agentit aloittavat pienestä, vakaasta aloituspisteestä ja heille opetetaan, mistä etsiä seuraavaksi, sen sijaan että ne kuormitettaisiin heti alussa.

Toteutamme tämän mekaanisesti. Erilliset linterit ja CI-tehtävät varmistavat, että tietopohja on ajan tasalla, ristiinlinkitetty ja rakenteeltaan oikein. Toistuva "doc-gardening"-agentti etsii vanhentunutta dokumentaatiota, joka ei vastaa koodin todellista toimintaa, ja avaa korjaavia pull request -pyyntöjä.

Koodipohjan kehittyessä myös Codexin suunnittelupäätösten oli kehityttävä.

Koska repositorio on kokonaan agentin tuottama, se on optimoitu ensisijaisesti Codexin luettavuutta varten. Samalla tavalla kuin tiimit pyrkivät parantamaan koodinsa navigoitavuutta uusille insinööritulokkaille, ihmisisinööriemme tavoitteena oli mahdollistaa se, että agentti voi päätellä koko liiketoiminta-alueen suoraan repositoriosta.

Agentin näkökulmasta kaikki, mitä se ei voi käyttää kontekstissa suorituksen aikana, ei käytännössä ole olemassa. Tieto, joka on Google Docsissa, keskusteluketjuissa tai ihmisten mielissä, ei ole järjestelmän käytettävissä. Se näkee vain paikalliset, repositorion versioidut artefaktit (esim. koodi, markdown, skeemat, suoritettavat suunnitelmat).

Opimme, että meidän täytyi ajan myötä lisätä yhä enemmän kontekstia repoon. Se Slack-keskustelu, joka linjasi tiimin arkkitehtuurimallin suhteen? Jos agentti ei löydä sitä, se on yhtä lukukelvoton kuin se olisi uudelle työntekijälle, joka aloittaa kolme kuukautta myöhemmin.

Codexin kontekstin lisääminen tarkoittaa oikean tiedon järjestämistä ja esille tuomista, jotta agentti voi tehdä päättelyä sen pohjalta, sen sijaan että sitä kuormitetaan tilapäisillä ohjeilla. Samalla tavalla kuin perehdyttäisit uuden tiimikaverin tuotteen periaatteisiin, suunnittelun normeihin ja tiimikulttuuriin (mukaan lukien emoji-mieltymykset), kun annat agentille tämän tiedon, se johtaa paremmin linjattuun lopputulokseen.

Tämä kehys selvensi monia kompromisseja. Suosimme riippuvuuksia ja abstraktioita, jotka voitiin sisäistää kokonaan ja joita voitiin perustella arkistossa. Teknologiat, joita usein kuvataan "tylsiksi", ovat agenteille helpompia mallintaa koostettavuuden, API:n vakauden ja koulutusdatan edustuksen vuoksi. Joissakin tapauksissa oli edullisempaa antaa agentin toteuttaa toiminnallisuuden osajoukot uudelleen kuin kiertää julkisten kirjastojen epäselvää ylävirran käyttäytymistä. Esimerkiksi sen sijaan, että olisimme ottaneet käyttöön yleisen p-limit-tyylisen paketin, toteutimme oman map-with-concurrency-avustajamme: se on tiiviisti integroitu OpenTelemetry-instrumentointiimme, sillä on 100 % testikattavuus ja se käyttäytyy täsmälleen niin kuin ajoympäristömme odottaa.

Kun järjestelmästä tuodaan enemmän sellaiseen muotoon, jota agentti voi tarkastella, validoida ja muokata suoraan, se lisää vipuvoimaa—ei vain Codexille, vaan myös muille agenteille (esim. Aardvark) jotka myös työskentelevät koodikannan parissa.

Pelkkä dokumentaatio ei riitä pitämään pelkästään agentin luomaa koodipohjaa johdonmukaisena. Vahvistamalla invariantteja, ei mikromanageerauksella, annamme agenttien toimittaa nopeasti perustaa horjuttamatta. Vaadimme esimerkiksi, että Codex jäsentää datamuodot rajalla⁠(avautuu uudessa ikkunassa), mutta emme ole tarkkoja siitä, miten se tapahtuu (malli näyttää pitävän Zodista, mutta emme määrittäneet kyseistä kirjastoa).

Agentit toimivat parhaiten ympäristöissä, joissa on tiukat rajat ja ennustettava rakenne⁠(avautuu uudessa ikkunassa), joten rakensimme sovelluksen jäykän arkkitehtuurimallin pohjalle. Kukin liiketoiminta-alue on jaettu kiinteään joukkoon kerroksia, jossa riippuvuussuunnat tarkistetaan huolellisesti ja sallittujen yhteyksien määrä on rajoitettu. Nämä rajoitukset pannaan täytäntöön mekaanisesti mukautettujen lintereiden (Codexin luomien) ja rakenteellisten testien avulla.

Alla oleva kaavio esittää säännön: kunkin liiketoiminta-alueen sisällä (esim. Sovellusasetukset), koodi voi riippua vain "eteenpäin" kiinteän kerrosjoukon läpi (Types → Config → Repo → Service → Runtime → UI). Monialaiset huolenaiheet (todennus, liittimet, telemetria, ominaisuusliput) tulevat yhden selkeän rajapinnan kautta: palveluntarjoajat. Mikään muu ei ole sallittua ja sitä valvotaan mekaanisesti.

Tämä on sellaista arkkitehtuuria, jota yleensä lykätään siihen asti, kunnes mukana on satoja insinöörejä. Koodausagenttien kanssa se on varhainen edellytys: rajoitteet mahdollistavat nopeuden ilman rappeutumista tai arkkitehtuurin poikkeamia.

Käytännössä valvomme näiden sääntöjen noudattamista mukautetuilla lintereillä ja rakenteellisilla testeillä sekä pienellä joukolla "makuinvariantteja". Esimerkiksi rakenteinen lokitus, skeemojen ja tyyppien nimeämiskäytännöt, tiedostokokorajoitukset ja alustakohtaiset luotettavuusvaatimukset varmistetaan staattisesti mukautetuilla lint-säännöillä. Koska lint-säännöt ovat mukautettuja, kirjoitamme virheilmoitukset siten, että voimme lisätä korjausohjeet agentin kontekstiin.

Ihmislähtöisessä työnkulussa nämä säännöt voivat tuntua pedanttisilta tai rajoittavilta. Agenttien avulla niistä tulee kertojia: kun ne on kerran koodattu, ne toimivat kaikkialla samanaikaisesti.

Samaan aikaan teemme selväksi sen, missä rajoitteilla on merkitystä ja missä ei. Tämä muistuttaa suuren suunnittelualustan organisaation johtamista: valvo rajoja keskitetysti, salli autonomia paikallisesti. Välität syvästi rajoista, oikeellisuudesta ja toistettavuudesta. Näiden rajojen sisällä annat tiimeille tai agenteille merkittävän vapauden siinä, miten ratkaisut esitetään.

Tuloksena syntyvä koodi ei aina vastaa ihmisten tyylillisiä mieltymyksiä, ja se on ihan okei. Kunhan tuotos on oikea, ylläpidettävä ja luettavissa tulevissa agenttiajoissa, se täyttää vaatimukset.

Ihmisten maku syötetään jatkuvasti takaisin järjestelmään. Tarkistuskommentit, refaktorointiin liittyvät pull request -pyynnöt ja käyttäjille näkyvät bugit tallennetaan dokumentaatiopäivityksinä tai suoraan työkaluihin. Kun dokumentaatio ei riitä, nostamme säännön koodiin

Codexin suoritustehon kasvaessa monet perinteiset tekniset normit muuttuivat haitallisiksi.

Repositorio toimii mahdollisimman vähäisellä määrällä estäviä yhdistämisportteja. Pull request -pyynno ovat lyhytikäisiä. Epävakaat testit käsitellään usein jatkoajoilla sen sijaan, että eteneminen estettäisiin loputtomasti. Järjestelmässä, jossa agenttien suoritusteho ylittää huomattavasti ihmisen huomion, korjaukset ovat edullisia ja odottaminen kallista.

Tämä olisi vastuutonta matalan suoritustehon ympäristössä. Tässä tapauksessa se on usein oikea valinta.

Kun sanomme, että Codex-agentit ovat luoneet koodipohjan, tarkoitamme kaikkea koodipohjassa olevaa.

Agentit tuottavat:

• Tuotekoodin ja testit
• CI-määrityksen ja julkaisutyökalut
• Sisäiset kehittäjätyökalut
• Dokumentaation ja suunnitteluhistorian
• Arviointivaljaat
• Arviointikommentit ja vastaukset
• Skriptit, jotka hallinnoivat itse repositoriota
• Tuotannon ohjauspaneelin määrittelytiedostot

Ihmiset pysyvät aina mukana, mutta työskentelevät eri abstraktiotasolla kuin aiemmin. Priorisoimme työn, käännämme käyttäjäpalautteen hyväksymiskriteereiksi ja validoimme tulokset. Kun agentti kohtaa vaikeuksia, pidämme sitä signaalina: tunnistamme, mitä puuttuu—työkalut, suojakaiteet, dokumentaatio—ja palautamme sen repositorioon, aina niin, että Codex itse kirjoittaa korjauksen.

Agentit käyttävät suoraan vakiokehitystyökalujamme. He hakevat tarkastuspalautteen, vastaavat siihen suoraan, tekevät päivityksiä ja usein sulauttavat ja yhdistävät omia pull request -pyyntöjään.

Kun yhä suurempi osa kehityssilmukasta koodattiin suoraan järjestelmään—testaus, validointi, katselmointi, palautteen käsittely ja palautuminen—repositorio ylitti hiljattain merkittävän kynnyksen, jolloin Codex voi ajaa uutta ominaisuutta alusta loppuun.

Kun agentti saa yhden kehotteen, se voi nyt:

• Tarkistaa koodipohjan nykyisen tilan
• Toistaa raportoidun bugin
• Tallentaa videon, jossa näytetään virhe
• Toteuttaa korjauksen
• Varmistaa korjauksen ajamalla sovellusta
• Tallentaa toisen videon, jossa näytetään ratkaisun toteutus
• Avata pull request -pyynnön
• Vastata agentin ja ihmisten palautteeseen
• Havaita ja korjata rakennusvirheet
• Eskaloida ihmiselle vain silloin, kun tarvitaan harkintaa
• Yhdistää muutoksen

Tämä toiminta riippuu suuresti repositorion erityisestä rakenteesta ja työkaluista, eikä sen pitäisi olettaa yleistyvän ilman vastaavaa panostusta—ainakaan vielä.

Agenttien täysi autonomia tuo mukanaan myös uusia ongelmia. Codex toistaa repositoriossa jo olemassa olevia malleja – myös epätasaisia tai epäoptimaalisia. Ajan myötä se johtaa väistämättä poikkeamaan.

Aluksi ihmiset hoitivat tämän manuaalisesti. Tiimimme käytti aiemmin jokaisen perjantain (20 % viikosta) tekoälysotkun siivoamiseen. Odotetusti se ei skaalautunut.

Sen sijaan aloimme koodata niin sanottuja "kultaisia periaatteita" suoraan repositorioon ja loimme toistuvan siivousprosessin. Nämä periaatteet ovat kantaa ottavia, mekaanisia sääntöjä, jotka pitävät koodikannan luettavana ja johdonmukaisena tulevia agenttien ajokertoja varten. Esimerkiksi: (1) suosimme jaettuja apuohjelmapaketteja itse tehtyjen apufunktioiden sijaan, jotta invariantit pysyvät keskitettyinä, (2) emme myöskään tutki dataa "YOLO-tyyliin"—validoimme rajat tai käytämme tyypitettyjä SDK:ita, jotta agentti ei voi vahingossa rakentaa arvailtujen rakenteiden varaan. Meillä on säännöllisin väliajoin joukko taustalla ajettavia Codex-tehtäviä, jotka etsivät poikkeamia, päivittävät laatuluokituksia ja avaavat kohdennettuja pull request -pyyntöjä. Useimmat näistä voidaan tarkistaa alle minuutissa ja yhdistää automaattisesti.

Tämä toimii kuten jätehuolto. Tekninen velka on kuin korkeakorkoinen laina: on lähes aina parempi maksaa sitä pois jatkuvasti pienissä erissä kuin antaa sen kasvaa korkoa korolle ja käsitellä sitä kivuliaissa erissä. Ihmisen maku tallennetaan kerran, ja sitä sovelletaan jatkuvasti jokaisella koodirivillä. Tämä mahdollistaa myös huonojen mallien havaitsemisen ja korjaamisen päivittäin, sen sijaan että ne leviävät koodipohjassa päivien tai viikkojen ajan.

Tämä strategia on tähän mennessä toiminut hyvin OpenAI:n sisäiseen julkaisuun ja käyttöönottoon asti. Rakentamalla todellisen tuotteen todellisille käyttäjille pystyimme ankkuroimaan investointimme todellisuuteen ja ohjaamaan itseämme kohti pitkäaikaista ylläpidettävyyttä.

Emme vielä tiedä, miten arkkitehtoninen johdonmukaisuus kehittyy ajan myötä täysin agenttien luomassa järjestelmässä. Opimme yhä, missä ihmisen harkinta tuo eniten hyötyä ja miten se voidaan koodata niin, että se kumuloituu. Emme myöskään tiedä, miten tämä järjestelmä kehittyy, kun malleista tulee ajan mittaan yhä suorituskykyisempiä.

On käynyt selväksi, että ohjelmistojen rakentaminen vaatii edelleen kurinalaisuutta, mutta kurinalaisuus näkyy enemmän tukirakenteissa kuin koodissa. Työkalut, abstraktiot ja palautesilmukat, jotka varmistavat koodipohjan johdonmukaisuuden, ovat yhä tärkeämpiä.

Vaikeimmat haasteemme keskittyvät nyt sellaisten ympäristöjen, palautesilmukoiden ja ohjausjärjestelmien suunnitteluun, jotka auttavat agentteja saavuttamaan tavoitteemme: kehittää ja ylläpitää monimutkaisia, luotettavia ohjelmistoja laajassa mittakaavassa.

Kun Codex-agentit ottavat hoitaakseen yhä suurempia osia ohjelmiston elinkaaresta, näillä kysymyksillä on entistäkin enemmän merkitystä. Toivomme, että jakamalla joitakin varhaisia oppeja autamme sinua miettimään, mihin kannattaa panostaa, jotta voit keskittyä asioiden rakentamiseen.