Näin CodeBuddy NPC toteuttaa AI Native Git -mallin

CodeBuddy NPC:n perusajatus on tehdä tekoälystä tunnistettu ja tapahtumapohjainen osallistuja olemassa olevaan Git-kehitysprosessiin – ei erillistä keskusteluikkunaa sen rinnalle. Kehittäjä voi kutsua roolin @-maininnalla Issuessa tai pull requestissa (PR), minkä jälkeen agentti voi työskennellä asynkronisesti ketjussa: tutki, suunnittele, toteuta, avaa PR, validoi CI:ssä, korjaa ja validoi uudelleen. 16

Git toimii agentin työmuistina

AI Native Git -mallissa Git-repositorion historia, Issuet, PR:t, CI/CD-ajojen tulokset ja laadunvarmistusportit muodostavat agentin jatkuvan toimintakontekstin. Vaatimuksia, lähdekoodia ja buildilokeja ei tarvitse kopioida erilliseen avustajaan, vaan NPC toimii niissä samoissa artefakteissa, joissa kehitystiimi jo työskentelee. 17

Käytännössä tämä muuttaa tekoälyn roolia: se ei vain ehdota koodia käyttäjän istunnossa, vaan saa työpyynnön tiimin tavallisesta työjonosta ja palauttaa työn sen tavallisiin tarkastus- ja hyväksymiskanaviin.

Roolit määritellään YAMLissa

CNB:ssä repositoriokohtaisia NPC-rooleja voidaan määritellä .cnb/settings.yml-tiedostossa. Määrittelyyn voidaan sisällyttää esimerkiksi roolin nimi, prompti, tietopohjan tuonnit ja käyttöliittymän toimintopainikkeet. 3

Dokumentoidut NPC-tapahtumat käynnistyvät, kun rooli mainitaan Issuen kuvauksessa tai kommentissa taikka PR:n kuvauksessa, tarkastuksessa tai kommentissa. Roolin varsinainen käyttäytyminen voidaan haluttaessa määrittää .cnb.yml-tiedostossa. 6 Tämä mahdollistaa erikoistuneet tehtäväjaot, kuten toteuttajan, koodikatselmoijan, selvittäjän tai työn koordinoijan roolit – sekä useiden NPC:iden rinnakkaisen käytön laajemmissa kokonaisuuksissa. 367

Autonominen toimitussilmukka

Kun NPC kutsutaan tehtävään, se voi hakea ja tulkita koodikannan, muodostaa toteutussuunnitelman, kirjoittaa koodia, avata PR:n, ajaa testit, lukea CI-virheet ja iteroida korjauksia, kunnes työ on valmiina hyväksyttäväksi. Koska toteutus on asynkroninen, kehittäjän ei tarvitse pysyä jatkuvasti vuorovaikutteisessa sessiossa agentin kanssa. 17

Tämä ei kuitenkaan tarkoita, että ihmistarkastus olisi tarpeeton. Kyse on työnkulun arkkitehtuurista ja automaation asteesta, ei todisteesta siitä, että jokainen tehtävä voitaisiin julkaista turvallisesti ilman ihmisen hyväksyntää. 17

CNB tarjoaa suoritusympäristön ja käyttöoikeusmallin

Agentin alla toimii CNB:n Git-hostaus, CI/CD-putket, artefaktirepositoriot ja pilvinatiivi kehitysympäristö. Putken YAML-määrityksissä voidaan valita Docker-kuvia, rakentaa väliaikaisia kuvia Dockerfilesta, käyttää dev containereita ja liitettyjä levyjä, määritellä suorittimia CPU-tunnisteilla sekä hyödyntää Docker-välimuistia. Näin buildit ja testit voidaan ajaa toistettavassa, eristetyssä ympäristössä kehittäjän oman koneen sijaan. 45

CNB syöttää putkiajoille väliaikaisen CNB_TOKEN-tunnuksen. Sitä voi käyttää koodin ja artefaktien lukuun ja kirjoitukseen sekä API-kutsuihin, ja tunnus tuhotaan ajon päättyessä. Käyttöoikeudet määräytyvät työnkulun käynnistäneen tapahtuman mukaan; NPC-identiteetillä ajettaville työnkuluille dokumentaatio kuvaa muun muassa koodi-, PR-, Issue- ja kommenttioikeuksia. 15

Jäljitettävyys säilyy Gitissä

Koska työ käynnistyy Issueista tai PR:istä, kirjautuu committeihin ja PR:iin sekä validoidaan putkissa ja laatupoorteissa, organisaation tuttu auditointiketju säilyy. Agentin tekemä työ ei jää irralliseksi, läpinäkymättömäksi toiminnaksi agentin ulkopuolelle. 19

CNB:n salaisuusrepositoriota koskeva dokumentaatio kuvaa myös arkaluonteisten tietojen suojausta käyttöoikeusrajoituksilla, toimintarajoituksilla, auditointilokeilla ja vesileimauksella. 9

Mikä erottaa mallin tavallisesta AI-koodiavusta?

Tencentin kuvaus "tekoälypohjaisesta ohjelmistokehitysyhteistyöstä" perustuu siihen, mihin kohtaan ohjelmistotoimitusta agentti asetetaan. Perinteinen AI-koodiavustus nopeuttaa ennen kaikkea ihmisen omaa koodinkirjoitusta. Yksittäisen tehtävän suorittava agentti taas delegoi rajatun toimenpiteen.

CodeBuddy NPC:n tavoite on toimia hallittuna tiimikaverina: se vastaanottaa työn tavallisista kehitysartefakteista, käyttää todellisia buildi- ja käytäntövalvontoja, voi jakaa työtä rooleittain ja sulkee palautesilmukan suunnittelun, toteutuksen, katselmoinnin, validoinnin ja korjaamisen välillä. 17