Tutorial 4 Prompting and Reviewing eu

Tutorial 4 · Prompt-ak eta berrikuspena

Helburua: meta-trebetasuna. Dagoeneko funtzionalitate bat eraiki dezakezu agente batekin — kapitulu hau hori arazorik gabe eta modu errepikagarrian egiteari buruzkoa da: lehen aldian asmatzen duten prompt-ak idaztea, diff-ak modu eraginkorrean berrikustea, gauzak oker doazenean iteratzea, eta bultzada saioen artean mantentzea.

← Aurrekoa: 3 Zure lehen ataza agentearekin · Hurrengoa: 5 Lokalizazioa

---

Egin prompt-ak arduradun gisa, ez bilaketa-koadro gisa

Agentea ingeniari júnior azkar, literal eta gogotsu bat da. Zuzendu on bat zuzenduko zenukeen bezala:

• Adierazi helburua eta murrizketak. "Gehitu endorse" ahula da. "Gehitu endorse connect patroiari jarraituz, hazidun RNGa soilik, probekin, langa berde geratzen da" indartsua da. Murrizketak dira ondo egokitzen den kodea lortzeko modua.
• Seinalatu adibideak. "Jarraitu renderConnect-ek erabiltzen duen patroia" deskribapen-paragrafo bat gainditzen du. Existitzen den kodea da espezifikaziorik onena.
• Eskatu plan bat editatu aurretik ez-hutsala den edozertan. Merkea da plan bat berbideratzea; garestia da editatutako hamar fitxategi desegitea.
• Ataza bat prompt bakoitzeko. "Gehitu endorse, birmoldatu RNGa ere, eguneratu README ere" biltzeak berrikusteko zaila den diff korapilatsu bat sortzen du.
• Emaiozu test-langa. "Exekutatu npm test eta ez jo eginda berde egon arte" agentea bere lana egiaztatzen duen zerbait bihurtzen du.

Berrikusi diff-a aldiro

Abiadura da agente baten helburu osoa — baina abiadura irakurri gabea da bug-ak nola argitaratzen diren. Eraiki berrikuspen-erreflexu azkar eta koherente bat:

1. Esparrua: aldatu al du behar zuena soilik? Zerikusirik ez duten lerro mugituak usain txarra dira.
2. Patroiak: inguruko kodearekin bat dator, mendekotasun berririk gabe eta src/-ren barruan S/I-rik gabe?
3. Proiektuaren arauak: biltegi honetan, hori da hazidun RNGa soilik (grep egin diff-ean Math.random bila), erabiltzaileak ikusten duen testua hizkuntza-paketeetan (ez kodean txertatua), eta txartel-lerroek inoiz ez gainditzea diseinuak betetzen duen zabalera.
4. Irisgarritasuna: irteera berriak --accessible gainditzen al du? Exekutatu lockedin --accessible <your command> eta egiaztatu testu lau eta garbi gisa irakurtzen dela — a11yFilter-etik pasatzen den glifo apaingarri berririk gabe.
5. Probak: proba berri bat al dago, eta benetan huts egingo luke funtzionalitatea hautsiko balitz? Galdetu: "Zein lerro aldatuko nuke proba berri hau huts eginaraztzeko?"
6. Exekutatu: npm test, gero exekutatu komandoa eta begiratu irteerari.

Ez duzu karaktere bakoitza ulertu behar — baina erabaki bakoitza ulertu behar duzu. Aldaketa bat azaldu ezin baduzu, eskatu agenteari azaltzeko onartu aurretik.

Iteratu berde ez dagoenean

Langa gorri bat urrats normal bat da, ez porrot bat. Konponketa feedback zehatza da:

"npm test-ek honekin huts egiten du: [paste the exact error]. renderEndorse-ren zabalera-probak txartel-lerro bakoitza ≤ 60 zutabe ikusgai izatea espero du. Konpondu proba ahuldu gabe."

Itsatsi benetako errore-testua. "Hautsita dago" agenteari asmatzen jartzen dio; stack trace-ak konpontzen jartzen dio. Eta nahiago izan elkarrizketa bera jarraitu hutsetik hasi baino — agenteak jada badu idatzi berri duenaren testuingurua. Bi edo hiru iteraziok bat egiten ez badute, egin atzera eta bir-esparratu: ataza prompt bakar baterako handiegia izan liteke.

Mantendu bultzada saioen artean

Benetako lanak jarraldi bat baino gehiago hartzen du. Bi ohiturek agente bat denboran zehar eraginkor mantentzen dute:

• Memoria / hitzarmenak. Zure agenteak memoria iraunkorra edo proiektu-argibideen fitxategi bat onartzen badu, erregistratu hor beti jarraitu behar dituen arauak (adib. "ausazkotasun guztiak pick/shuffle erabili behar du", "exekutatu npm test eginda deklaratu aurretik"). Hitzarmen bat behin adierazten duzu prompt bakoitzean egin beharrean.
• Eskualdatze-ohar bat. Biltegi honek egoera-dokumentu labur eta garbitu bat gordetzen du docs/HANDOFF.md-en: zer den proiektua, nola dagoen eraikita, nola probatzen den, eta zer datorren hurrena. Itzultzen zarenean (edo lankide bati — edo beste agente bati — eskualdatzen diozunean), ohar horrek testuingurua segundotan berreraikitzen du. Eskatu agenteari eguneratuta mantentzeko aldaketa baten parte gisa.

Mantentzea merezi duten babes-hesiak

• Langa ez da negoziagarria. Proba berdeak ezer argitaratu aurretik. Horrek uzten dizu azkar mugitzen eta irteeraz fidatzen.
• Zu zara erregistroko berrikuslea. Agenteak idazten du; zuk erabakitzen duzu. Diff bat onartzeak horren alde egiten duzula esan nahi du.
• Urrats txiki eta egiaztagarriak jauzi erraldoi bat gainditzen dute. Onartutako aldaketa bakoitzak app-a funtzionatzen utzi beharko luke.

---

✅ Probatu zure agentearekin

1. Idatzi mentor komando batentzako paragrafo bateko espezifikazio bat ("eskatu gabeko aholkuak banatzen ditu"), murrizketak barne, eta agenteak probak-lehenengo eraiki dezala — plana, probak, kodea, langa — urrats bakoitzean berrikusiz.
2. Eskatu agenteari docs/HANDOFF.md eguneratzeko komando berria aipa dezan.
3. Hautsi zerbait nahita (adib. ezabatu pool-sarrera bat), exekutatu npm test, eta praktikatu agenteari huts zehatza ematea konpontzeko.

---

Nora joan hurrena

• Begiratu benetako kodea src/lockedin.js-en — orain badakizu bere forma.
• Irakurri docs/HANDOFF.md proiektuaren beraren egoera- eta arkitektura-oharrentzat.
• Gozatu txantxekin Komando-erreferentzia-n.

Hori da tutoriala. Orain AI agente bat zuzendu dezakezu benetako softwarea eraiki eta aldatzeko test-langa baten atzean — imajina daitekeen adibiderik harroputzena erabiliz. Ados? 👇