Tekijä: Kwame Boateng
Tekoälyavusteinen koodaus kuvataan usein pariohjelmoinnin nopeammaksi versioksi. Tämä vertaus on nykyään liian suppea. Kun agentti voi tarkastella repositoriota, muuttaa useita tiedostoja, suorittaa työkaluja, luoda esikatselun ja avata pull requestin, yhteistyön keskeinen ongelma ei enää ole yksinkertaisesti ”Pystyykö se kirjoittamaan koodia?” Vaan ”Voivatko ihmiset nähdä, tarkistaa, hyväksyä ja myöhemmin rekonstruoida, mitä tapahtui?”
Siksi agenttiavusteisten ohjelmistotiimien tärkein suunnanmuutos saattaa olla siirtyminen yksityisistä kehotteista näkyviin työtiloihin. Esimerkiksi Slack Code kuvataan kokonaisuudeksi, jossa projektikanavat yhdistyvät koodausagentteihin, koodimuutosten auditointiin, reaaliaikaisiin HTML-esikatseluihin, palautteen ja hyväksynnän työnkulkuihin, automaattiseen arkistointiin ja auditointilokeihin. GitHubin Copilot-sovellukseen on myös lisätty ”Oma työ” -ruutu eri projektien issueiden ja pull requestien järjestämistä varten. Nämä ominaisuudet viittaavat käytännölliseen periaatteeseen: agentin työn pitäisi näyttää vähemmän läpinäkymättömältä vastaukselta ja enemmän hallitun tuotantoprosessin läpi kulkevalta muutoskokonaisuudelta.
Keskustelu ei ole työmerkintä
Keskustelu agentin kanssa voi olla hyödyllinen idean tutkimisessa, mutta se on heikko järjestelmä tietojen tallentamiseen. Tärkeitä yksityiskohtia voi hautautua pitkään keskusteluketjuun: mitkä tiedostot muuttuivat, mitä komentoja suoritettiin, mitä oletuksia agentti teki, minkä tarkistaja hylkäsi ja eroavatko lopulliset tulokset ensimmäisestä ehdotuksesta.
Pysyvä työtila tekee näistä yksityiskohdista tarkasteltavia. Sen pitäisi yhdistää pyyntö tiettyyn repositorioon tai projektiin, säilyttää agentin suunnitelma, näyttää työkalujen toiminnot ja tiedostomuutokset, linkittää testit ja esikatselut sekä kirjata, kuka hyväksyi tuloksen. Käyttöliittymä voi vaihdella—issue-seuranta, pull request, yhteistyökanava tai agenttikonsoli—mutta tietojen pitäisi säilyä istunnon päättymisen jälkeenkin.
Tällä on merkitystä tavanomaisista teknisistä syistä, ei ainoastaan vaatimustenmukaisuuden vuoksi. Jos virhe ilmenee kahden viikon kuluttua, tiimi tarvitsee muutakin kuin lopullisen diffin. Sen on ehkä tiedettävä alkuperäinen vaatimus, luotu suunnitelma, testitulokset, tarkistajan kommentit ja se, hyväksyikö ihminen nimenomaisesti riskialttiin kompromissin. Pysyvä tallenne nopeuttaa selvitystyötä.
Näkyvän työn viisi kerrosta
Koodausagentteja käyttöön ottavat tiimit voivat käsitellä jokaista muutosta pienenä, tarkasteltavana tapaustiedostona. Viisi kerrosta ovat erityisen hyödyllisiä:
- Tarkoitus: issue, hyväksymiskriteerit, rajoitteet ja pyydetty laajuus.
- Suunnitelma: agentin ehdottama lähestymistapa ennen tiedostojen muokkaamista. Ei-triviaalissa tehtävässä tämä on hyväksynnän tarkistuspiste, ei koriste.
- Diffi: täsmälliset lisäykset, poistot, riippuvuusmuutokset, asetusten muokkaukset ja luodut aineistot.
- Näyttö: testitulokset, lint-tuloste, tietoturvatarkistukset, kuvakaappaukset sekä tarvittaessa reaaliaikainen tai käyttöönotettavissa oleva esikatselu.
- Päätöstallenne: tarkistajan kommentit, pyydetyt muutokset, hyväksyntä, hylkäys, palautus tai jatkotyö.
Tarkoituksena ei ole pakottaa jokaista muutosta raskaan komitean käsittelyyn. Kirjoitusvirheellä ja maksupolun muutoksella ei pitäisi olla identtisiä kontrolleja. Tarkoitus on suhteuttaa tarkastelun taso mahdolliseen vaikutukseen.
Hyväksynnät pitäisi sitoa toimintoihin
”Ihminen silmukassa” on liian epämääräinen ollakseen hyödyllinen kontrolli. Henkilö saattaa hyväksyä suunnitelman näkemättä tuloksena syntyvää diffiä tai hyväksyä koodimuutoksen huomaamatta, että agentti muokkasi samalla myös käyttöönoton asetustiedostoa. Paremmissa työnkuluissa ilmaistaan, mitä hyväksyntä sallii.
Tiimi voisi esimerkiksi sallia agentin lukea repositoriota ja suorittaa paikallisia testejä automaattisesti, vaatia hyväksynnän ennen kirjoittamista nimetyn haaran ulkopuolelle sekä vaatia erillisen hyväksynnän ennen yhdistämistä tai käyttöönottoa. Agentti voisi ehdottaa tietokantamigraatiota, mutta sen suorittaminen tuotannossa voitaisiin kieltää. Arabiemiirikuntien ehdotettu lähestymistapa, jossa luokitellaan, mitkä tehtävät agentit voivat suorittaa ja mitä ne voivat vain suositella, heijastaa tätä laajempaa mallia: autonomia pitäisi määrittää tehtäväkohtaisesti, ei olettaa sitä yleisesti.
Hyväksynnälle tarvitaan myös rajaus ja vanheneminen. Hyväksyntä ”laskeutumissivun tekstin päivittämiselle” ei saisi hiljaisesti antaa lupaa uuden analytiikkapakettin lisäämiseen. Eilen hyväksytyn suunnitelman ei pitäisi automaattisesti kattaa tämän päivän olennaisesti muuttunutta diffiä. Käyttöliittymän pitäisi tehdä nämä rajat näkyviksi.
Esikatselut muuttavat tarkistamisen tarkasteluksi
Koodin tarkistaminen on usein helpompaa, kun ihmiset voivat tarkastella lopputulosta sen sijaan, että he päättelevät sen lähdetiedostoista. Reaaliaikainen HTML-esikatselu voi paljastaa rikkoutuneet välit, puuttuvat tilat, saavuttamattomat ohjaimet tai tahattoman navigointimuutoksen, jonka tarkistaja saattaa tekstimuotoisessa diffissä ohittaa.
Esikatselut eivät ole todiste oikeellisuudesta. Niiden pitäisi olla testien ja lähdekoodin tarkistamisen rinnalla, ei korvata niitä. Ne luovat kuitenkin yhteisen keskustelukohteen: tarkistaja voi osoittaa tiettyä näyttöä, tilaa tai vuorovaikutusta ja jättää palautteen liitettynä ehdotettuun muutokseen.
Tämä on erityisen arvokasta, kun tarkistukseen osallistuu muita kuin teknisiä asiantuntijoita. Tuotepäällikkö ei ehkä pysty arvioimaan framework-muutosta, mutta hän voi olla oikea henkilö vahvistamaan, että työnkulku vastaa vaatimusta. Suunnittelija voi tarkistaa visuaalisen regression. Tietoturva-asiantuntija voi keskittyä käyttöoikeuksiin ja tietojen käsittelyyn. Agenttiavusteinen työtila voi ohjata kunkin kysymyksen henkilölle, jolla on parhaat edellytykset vastata siihen.
Diffit tarvitsevat kontekstia, eivät vain värejä
Tutut punainen–vihreä-diffit ovat edelleen välttämättömiä, mutta agenttien luomat muutokset voivat olla niin laajoja, että ne kuormittavat tarkistajaa. Tiimien pitäisi pyytää agentteja pitämään commitit tai muutosryhmät suppeina, selittämään, miksi kutakin merkittävää tiedostoa muutettiin, ja erittelemään luodut tai toimittajan tiedostot erikseen.
Hyödyllisiä tarkistuskysymyksiä ovat:
- Miten käyttäjälle näkyvä toiminta muuttui?
- Mitä tiedostoja muutettiin vain toteutuksen tukemiseksi?
- Mitä oletuksia agentti teki olemassa olevasta toiminnasta?
- Mitä testejä lisättiin tai muokattiin, ja mitä testejä ei suoritettu?
- Voiko tämä muutos vaikuttaa käyttöoikeuksiin, tietojen säilytykseen, laskutukseen tai ulkoisiin ohjelmointirajapintoihin?
Nämä kysymykset muuttavat tarkistamisen epämääräisestä ”katso tämä läpi” -pyynnöstä toistettavaksi tutkimiseksi. Ne auttavat myös paljastamaan yleisen virhetilanteen: uskottavan ominaisuuden, jota täydentää puutteellinen testipäivitys tai tahaton määritysmuutos.
Arkistoi merkityksellinen päättely
Jokaisen mallikeskustelun jokaisen osan säilyttäminen ei ole automaattisesti hyödyllistä. Pitkiä historiatietoja voi olla kallista tallentaa ja vaikeaa etsiä, ja kontekstin tiivistämistä koskeva tutkimus varoittaa, että yhteenvedoista voi kadota tärkeää tietoa. Käytännöllisen tarkastusketjun tulisi siksi säilyttää päätösten kannalta olennaiset aineistot sen sijaan, että kaikki tallennettaisiin erotuksetta.
Säilytä vähintään pyyntö, hyväksytty suunnitelma, lopullinen diff, työkalujen ja testien tulokset, esikatselun tai käyttöönoton viite, tarkistajien päätökset sekä mahdollisesti myönnetyt poikkeukset. Jos agentti käytti ulkoisia lähteitä tai haki sisäisiä asiakirjoja, kirjaa asiaankuuluvat lähdeviitteet ja kohta, jossa ne vaikuttivat muutokseen. Korkean riskin työssä koko vuorovaikutus- ja suorituslokin säilyttäminen voi olla perusteltua.
Tee tietueista peukaloinnin paljastavia silloin, kun panokset sitä edellyttävät, ja määritä säilytyssäännöt ennen kriisiä. Tarkastusketju, joka katoaa kanavan arkistoinnin yhteydessä tai josta ei voi erottaa muutettua tulosta alkuperäisestä, ei tue vakavaa tutkintaa.
Mitä tämä muuttaa ohjelmistoalan urien kannalta
Nouseva taito ei ole pelkästään parempien kehotteiden kirjoittaminen. Kyse on työn suunnittelusta niin, että toinen henkilö voi tarkastaa sen ja luottaa siihen. Kehittäjien on osattava määritellä hyväksymiskriteerit, pilkkoa tehtävät, tarkistaa diffejä laajassa mittakaavassa, rakentaa merkityksellisiä testejä ja päättää, missä kohdassa agentin on pysähdyttävä ja kysyttävä.
Tuote- ja suunnitteluammattilaisilla on suurempi rooli esikatselujen tarkistamisessa ja tarkoituksen täsmentämisessä. Laadunvarmistusinsinöörit voivat auttaa hyväksymisporttien ja virhetilanteiden määrittelyssä. Tekniikan esihenkilöiden on mitattava läpimenoa palkitsematta näkymättömästä riskinotosta. Teknisten kirjoittajien ja operaatioasiantuntijoiden panos voi tehdä päätöksistä, poikkeuksista ja käyttöohjeista kestäviä.
Hyödyllinen harjoitus on ottaa tavanomainen ominaisuus ja kartoittaa sen todistusketju: pyyntö, suunnitelma, haara, diff, testit, esikatselu, hyväksyntä, julkaisu ja palautus. Kysy sitten, missä tuleva työtoveri joutuisi arvaamaan. Jokainen arvaus on ehdokas paremmaksi työtilaksi, selkeämmäksi käyttöoikeudeksi tai kestävämmäksi tietueeksi.
Yksinkertainen toimintaperiaate
Anna agenttien edetä nopeasti näkyvässä ja palautettavassa toimintatilassa. Tarjoa niille määritelty työtila, rajoita arkaluonteisia toimia, edellytä hyväksyntää merkityksellisissä rajakohdissa, liitä muutosaineisto muutokseen ja säilytä lopullinen päätös. Tavoitteena ei ole hidastaa automaatiota, kunnes se muistuttaa manuaalista koodausta. Tavoitteena on tehdä nopeudesta yhteensopivaa vastuuvelvollisuuden kanssa.
Agenttiavusteisessa kehityksessä paras yhteistyökumppani ei ole järjestelmä, joka tuottaa yksinään eniten koodia. Se on järjestelmä, jonka työn voi ymmärtää, kyseenalaistaa, hyväksyä, perua ja josta voi oppia.
