Kielimallit, konteksti ja vakuuttavat virheet

Kyvykkyys ei kerro, mitä malli tietää tästä tehtävästä

Kielimalli tuottaa vastauksen oppimiensa rakenteiden ja tehtävän aikana saamansa tiedon perusteella. Nykyiset mallit pystyvät vaativaan päättelyyn ja hyödylliseen ohjelmistotyöhön. Ne voivat myös kirjoittaa yksityiskohtaisen vastauksen, jonka keskeinen oletus on väärä.

Frontier-kielimalli kuvaa muuttuvaa kyvykkyystasoa. Nimitys ei takaa, että malli olisi lukenut repositoriosi, tuntisi asennetun riippuvuuden version tai tietäisi liiketoiminnan kirjaamattoman säännön. Näiden tietojen pitää tulla tehtävän ympäristöstä. Työkaluja käyttävä agentti voi hakea niitä. Keskustelu ilman tarvittavaa pääsyä ei voi.

Kun vastaus näyttää väärältä, erottele kaksi kysymystä. Pystyisikö malli ratkaisemaan ongelman oikeilla tiedoilla? Saiko se nämä tiedot? Mallin vaihtaminen voi auttaa ensimmäiseen. Puuttuvan säännön lisääminen tai riippuvuuden tarkistaminen auttaa toiseen.

Kontekstilla on rajat

Konteksti tarkoittaa nykyiseen vastaukseen käytettävissä olevaa tietoa: ohjeita, tiedostoja, keskustelua ja työkalujen tuloksia. Eri tuotteet valitsevat, säilyttävät, tiivistävät ja hakevat tietoa eri tavoin. Kansion liittäminen ei tarkoita, että malli olisi lukenut kaikki sen tiedostot. Pitkän keskustelun alussa annettu ohje ei välttämättä ole myöhemmin yhtä hyvin käytettävissä.

Suurempi konteksti ei automaattisesti ole parempi. Ajantasainen arkkitehtuuripäätös voi auttaa enemmän kuin tuhat asiaan liittymätöntä tiedostoa. Vanhentunut migraatio-ohje voi johtaa harhaan juuri siksi, että se näyttää luotettavalta.

Kuvitteellisen tiliasetusten muutoksen kontekstiin voisivat kuulua nykyinen route, sen authorization-middleware, tietomalli ja olemassa oleva testi. Lisää reunaehto: ”Jäsen saa muuttaa oman näyttönimensä mutta ei organisaatiorooliaan.” Nyt mallilla on täsmällinen sääntö säilytettäväksi.

Pura väite tarkastettaviksi osiksi

Vastaus voi sanoa: ”Endpoint on turvallinen, koska middleware tarkistaa omistajuuden.” Käyttääkö endpoint todella kyseistä middlewarea? Tarkistaako middleware omistajuuden vai pelkän kirjautumisen? Tuleeko käyttäjän identiteetti luotetusta lähteestä?

Pyydä tiedoston ja funktion nimet. Lue toteutus. Aja kielteinen testi toisena käyttäjänä. Viittaus repositorioon kertoo, mistä tarkistaa. Se ei vielä osoita, että selitys vastaa koodia.

Sama koskee API:a. Jos generoitu koodi kutsuu funktiota, jota asennettu kirjasto ei tarjoa, tarkista versio ja virallinen dokumentaatio ennen koko riippuvuusketjun vaihtamista. Muuten pieni epäselvyys voi kasvaa turhaksi migraatioksi.

Muuta epävarmuus seuraavaksi tehtäväksi

”Ole tarkka” ei ole tarkistussuunnitelma. Pyydä oletus, sen tarkistamiseen tarvittava näyttö ja väärän oletuksen seuraus. Esimerkiksi: ”Emme ole varmistaneet tenant-rajausta. Tarkasta request handler ja lisää testi, jossa toisen tenantin käyttäjä pyytää samaa tietuetta.”

Toteutusta koskevissa ristiriidoissa suora näyttö tarkasteltavasta järjestelmäversiosta painaa paljon. Dokumentti voi kuvata tavoitetta. Koodi ja testit auttavat selvittämään, mitä nykyinen versio tekee. Älä peitä niiden välistä eroa valitsemalla mukavampaa tulkintaa.

Johtajan ei tarvitse lukea jokaista koodiriviä. Hänen kannattaa silti kysyä, mitkä oletukset on tarkistettu, mitkä ovat auki ja kuka selvittää ne ennen julkaisua. Se kertoo työn hallinnasta enemmän kuin käytetyn kielimallin nimi.