Testivetoinen kehitys ja AI-agentit vaikuttavat paperilla täydelliseltä yhdistelmältä. TDD tarjoaa selkeän palkkiosignaalin, joka ohjaa koodin kirjoittamista. AI-agentit hyötyvät selkeistä ohjeista ja välittömästä palautteesta. Teorian mukaan tämän pitäisi toimia saumattomasti.
Käytännössä ei toimi. Ainakaan ei ilman tietoista kontekstin hallintaa.
Konteksti-ikkunan hallitsevuus
Ongelma on siinä, miten kielimallien konteksti-ikkuna toimii. Kun annat agentille komennon “kirjoita testit x ja y, ja sen jälkeen toteuta toiminnallisuus z”, testien kirjoitus alkaa hallita kontekstia. Ne sekoittuvat z:n vaatimuksiin.
Tulos: koodi kirjoitetaan läpäisemään testit, ei täyttämään alkuperäisiä vaatimuksia. Tämä kuulostaa hyvältä, mutta käytännössä testit kirjoitetaan jo tietoisena siitä, mitä z sisältää. Ne eivät ole riippumattomia spesifikaation.
Sama ilmiö tapahtuu käänteisena. Jos komento on “toteuta toiminnallisuus z ja sen jälkeen testit x ja y”, testit kirjoitetaan tietoisena z:n sisäisestä logiikasta. Ne testaavat vain ne tapaukset, joille koodi varmasti toimii.
Kummassakin tapauksessa menetät sen, mikä tekee TDD:stä tehokkaan: riippumattoman spesifikaation, joka pakottaa koodin täyttämään ulkoiset vaatimukset.
Erilliset kontekstit ovat ratkaisu
Ratkaisu on yksinkertainen mutta vaatii kurinalaisuutta: testit ja toteutus on toteutettava erillisissä konteksteissa.
Tämä tarkoittaa käytännössä sitä, että käytät yhtä agenttia tai istuntoa testien suunnitteluun ja toista toteutukseen. Kontekstit eivät kommunikoi keskenään kuin lopputuloksen kautta. Testi kirjoitetaan ilman tietoa siitä, miten toiminnallisuus toteutetaan. Toteutus kirjoitetaan ilman tietoa siitä, miten testit on rakennettu sisäisesti.
Tämä tuntuu aluksi kömpelöltä. Se vaatii enemmän työtä. Mutta se säilyttää sen, mikä tekee TDD:stä arvokkaan: todellisen riippumattomuuden vaatimusten ja toteutuksen välillä.
Session splitting
Käytännössä tämä tarkoittaa session splitting -lähestymistapaa. Eri agentit tai istunnot käsittelevät tehtävän eri vaiheita. Yksi vastaa arkkitehtonisesta suunnittelusta, toinen implementaatiosta, kolmas testaamisesta.
Jokainen istunto saa oman kontekstinsa, omat ohjeensa, oman fokuksensa. Ne eivät pääse sekoittamaan huomiota toisiinsa. Lopputuloksena koodi, joka todella vastaa vaatimuksia eikä vain läpäise testejä.
AI-avusteinen TDD korostaa mikroiterointeja
Kun TDD yhdistetään AI:hin oikein, se korostaa mikroiterointeja. Kehittäjä kirjoittaa pienen epäonnistuvan testin, joka määrittelee tietyn käyttäytymisen. Kielimalli tuottaa vain sen vähimmäiskoodin, joka tarvitaan testin läpäisemiseen.
Tämä estää mallia generoimasta epäolennaista tai ylisuurta logiikkaa, mikä on yleinen ongelma kun kielimalleja pyydetään ratkaisemaan laajoja ongelmia ilman selkeitä rajoitteita.
Mutta tämä toimii vain jos testit todella rajaavat ongelmaa, eivätkä vain vahvista sitä mitä koodi jo tekee. Ja tämä vaatii erillisiä konteksteja.
Ei oikotietä
TDD ja AI voivat toimia yhdessä, mutta se vaatii tietoista työtä. Kontekstin hallinta ei ole tekninen yksityiskohta, se on keskeinen osa prosessia. Jos haluat hyödyntää kummankin vahvuudet, älä odota sen tapahtuvan automaattisesti.
Rakenna prosessi, joka pitää testit ja toteutuksen erillään. Se tuntuu hitaalta aluksi, mutta tuottaa koodia joka todella toimii.
Katso myös Konteksti-ikkunan kokoinen arkkitehtuuriongelma — miten sama kontekstin hallintaongelma ilmenee laajemmassa monirepoympäristössä.
Bytecraft auttaa insinööritiimejä rakentamaan AI-avusteisia kehitysprosesseja, jotka eivät tingi laadusta. Tutustu konsultointipalveluihimme nähdäksesi miten lähestymme tätä käytännössä.
