Kielimallien konteksti-ikkuna on rajallinen. Tämä ei ole tekninen yksityiskohta, se on arkkitehtoninen rajoite joka muokkaa sitä, miten AI-avusteista kehitystä kannattaa tehdä.
Monirepoympäristössä tämä rajoite tulee näkyväksi nopeasti. AI-agentti, joka työskentelee yhden repon sisällä, ei näe mitä tapahtuu toisessa. Se ei ymmärrä miten frontend-toiminto linkittyy backend-endpointtiin. Se ei tiedä mitkä asiat liittyvät toisiinsa.
Tämä ei ole mallin vika. Se on kontekstin puutetta.
Yhteinen konteksti täytyy rakentaa
Eräällä asiakkaalla kokeiltiin useita tapoja ratkaista tämä. Muutaman variaation jälkeen palattiin siihen, että tarvitaan yhteinen konteksti. Käytännössä tämä tarkoittaa jaettuja tiedostoja kuten prompt.md ja instructions.md, jotka kuvaavat miten eri osat liittyvät toisiinsa.
Yksinkertaisimmillaan tämä tarkoittaa sitä, että voidaan linkittää frontissa tapahtuva toiminto backendin endpointtiin. Ei mitään monimutkaista, mutta kriittistä. Ilman tätä linkitystä agentti ei tiedä mitä pitää muuttaa kun halutaan tehdä jotain.
Mikä määrä yksityiskohtia on hyvä, on oma kysymyksensä. Mutta tämä auttaa mallia etsimään vastauksen siihen mitä pitää muuttaa ja mitkä asiat liittyvät toisiinsa.
Workspace-rakenne
Käytännössä tämä toteutetaan siten, että on yksi kansio tai workspace, joka sisältää alikansioina repot. Yksi kansioista voi olla ohjeistus ja komennot, tai pääkansio voi olla oma projektinsa jossa on Gitin submoduuleita.
Tämän ympärille voi rakentaa automaatiota. Backendin endpointtien kaivaminen automaattisesti OpenAPI-kuvauksen pohjalta. Käänteisesti fronttiin meneminen ja katsominen mitä kutsutaan missäkin. Frontin toiminnon selvittely LLM-työkalun ja selaimen avulla.
Voi olla oma komento tai workflow kuvauksen päivittämiselle ja yhdistämiselle. Aputyökalut useamman linkittyvän merge requestin ja repojen käsittelyyn.
Projektikohtainen kuvaus
Lopputuloksena on kuvaus, esimerkiksi YAML tai JSON, siitä mitä tapahtuu missäkin kun käyttäjä painaa painiketta käyttöliittymässä. Tämä tiedosto yhdessä yleisen ohjeistuksen ja projektikohtaisen kuvauksen kanssa muodostaa pohjan perussuunnitelman luomiselle kun lähdetään tekemään jotain muutosta.
Tämä ei ole kertakäyttöinen työ. Kuvaus täytyy päivittää kun arkkitehtuuri muuttuu. Mutta päivityksen voi tiputtaa suoraan mallille ja kutsuttaville skripteille. Ei tarvitse ylläpitää käsin.
Hieno puoli on, että kun tämä rakenne on olemassa, agentti alkaa toimia. Se näkee kokonaisuuden. Se ymmärtää riippuvuudet. Se tietää mitä muuttaa kun toiminnallisuutta halutaan muuttaa.
Konteksti määrittää mitä agentti näkee
Kielimallien tehokas konteksti-ikkuna on rajattu. Tämä ei muutu lähitulevaisuudessa. Voit antaa mallille enemmän tokeneita, mutta se mitä se todella pystyy hyödyntämään pysyy rajallisena.
Siksi kontekstin rakentaminen ei ole valinnaista. Se on edellytys sille, että agentti pystyy työskentelemään monirepoympäristössä ilman jatkuvaa sokeita pisteiden kanssa kompurointia.
Älä odota mallin ratkaisevan tätä. Rakenna konteksti sille.
Katso myös Miksi TDD ja AI eivät sovi yhteen ilman erillistä kontekstia — miten kontekstin eristäminen toimii yksittäisen tehtävän tasolla. Laajemmasta kuvasta siitä, miten AI vahvistaa nykyisiä käytäntöjä: AI on nykyisen tilanteen kerroin.
Bytecraft auttaa insinööritiimejä rakentamaan AI-avusteisia kehitystyönkulkuja, jotka toimivat kielimallien rajoitteiden kanssa eikä niitä vastaan. Tutustu konsultointipalveluihimme nähdäksesi miten lähestymme tätä käytännössä.
