Deur Kwame Boateng
KI-gesteunde kodering word dikwels beskryf as ’n vinniger weergawe van paarprogrammering. Daardie vergelyking is nou te eng. Wanneer ’n agent ’n bewaarplek kan inspekteer, verskeie lêers kan verander, nutsmiddels kan uitvoer, ’n voorskou kan genereer en ’n pull-versoek kan oopmaak, is die sentrale samewerkingsprobleem nie meer bloot “Kan dit kode skryf?” nie. Dit is “Kan mense sien, hersien, goedkeur en later rekonstrueer wat gebeur het?”
Dit is waarom die belangrikste ontwerpverskuiwing in agent-gesteunde sagtewarespanne moontlik die skuif van private aanwysings na sigbare werkruimtes is. Slack Code word byvoorbeeld beskryf as ’n kombinasie van projekkanale met koderingsagente, ouditering van kodeverskille, lewendige HTML-voorskoue, terugvoer- en goedkeuringswerkvloeie, outomatiese argivering en ouditlogboeke. GitHub se Copilot-toepassing het ook ’n “My werk”-venster bygevoeg om kwessies en pull-versoeke oor projekte heen te organiseer. Hierdie funksies dui op ’n praktiese beginsel: ’n agent se werk moet minder soos ’n ondeursigtige antwoord lyk en meer soos ’n stel veranderinge wat deur ’n beheerde produksieproses beweeg.
Die klets is nie die werkrekord nie
’n Gesprek met ’n agent kan nuttig wees om ’n idee te verken, maar dit is ’n swak stelsel van rekordhouding. Belangrike besonderhede kan in ’n lang gesprek begrawe word: watter lêers verander het, watter opdragte uitgevoer is, watter aannames die agent gemaak het, wat ’n beoordelaar verwerp het en of die finale resultaat van die eerste voorstel verskil.
’n Volhoubare werkruimte maak daardie besonderhede inspekteerbaar. Dit behoort die versoek aan ’n spesifieke bewaarplek of projek te koppel, die agent se plan te bewaar, nutsaksies en lêerveranderings te wys, na toetse en voorskoue te skakel en aan te teken wie die resultaat goedgekeur het. Die presiese koppelvlak kan verskil—’n kwessiespoorder, pull-versoek, samewerkingskanaal of agentkonsole—maar die inligting behoort beskikbaar te bly nadat die sessie beëindig is.
Dit is om gewone ingenieursredes belangrik, nie slegs vir voldoening aan voorskrifte nie. As ’n fout twee weke later verskyn, het ’n span meer as die finale diff nodig. Dit moet dalk die oorspronklike vereiste, die gegenereerde plan, die toetsbewyse, die beoordelaar se opmerkings en of ’n mens uitdruklik ’n riskante kompromis aanvaar het, ken. ’n Volhoubare rekord verkort daardie ondersoek.
Vyf lae van sigbare werk
Spanne wat koderingsagente aanvaar, kan elke verandering as ’n klein, inspekteerbare gevalle-lêer hanteer. Vyf lae is besonder nuttig:
- Bedoeling: die kwessie, aanvaardingskriteria, beperkings en aangevraagde omvang.
- Plan: die agent se voorgestelde benadering voordat dit lêers wysig. Vir ’n nie-triviale taak is dit ’n goedkeuringskontrolepunt, nie versiering nie.
- Diff: die presiese byvoegings, skrappings, afhanklikheidsveranderings, konfigurasiewysigings en gegenereerde bates.
- Bewyse: toetsresultate, uitvoer van lintnutsmiddels, sekuriteitskontroles, skermkiekies en, waar relevant, ’n lewendige of ontplooibare voorskou.
- Besluitrekord: beoordelaars se opmerkings, aangevraagde veranderinge, goedkeuring, verwerping, terugrol of opvolgwerk.
Die doel is nie om elke verandering deur ’n swaar komiteeproses te dwing nie. ’n Tikfout en ’n verandering aan ’n betalingsvloei behoort nie identiese kontroles te hê nie. Die doel is om die vlak van ondersoek eweredig aan die moontlike impak te maak.
Goedkeurings behoort aan handelinge gekoppel te wees
“Mens in die lus” is te vaag om ’n nuttige beheermaatreël te wees. ’n Persoon kan ’n plan goedkeur sonder om die gevolglike diff te sien, of ’n kodeverandering goedkeur sonder om op te merk dat die agent ook ’n ontplooiingslêer gewysig het. Beter werkvloeie stel duidelik wat goedkeuring toelaat.
’n Span kan byvoorbeeld ’n agent toelaat om outomaties ’n bewaarplek te lees en plaaslike toetse uit te voer, goedkeuring vereis voordat daar buite ’n aangewese tak geskryf word, en ’n afsonderlike goedkeuring vereis voordat daar saamgevoeg of ontplooi word. ’n Agent kan ’n databasismigrasie voorstel, maar verbied word om dit in produksie uit te voer. Die VAE se voorgestelde benadering om te klassifiseer watter take agente mag voltooi teenoor slegs aanbeveel, weerspieël hierdie breër patroon: outonomie behoort per taak toegeken te word, nie wêreldwyd veronderstel te word nie.
Goedkeurings het ook omvang en ’n vervaldatum nodig. ’n Goedkeuring vir “werk die teks op die bestemmingsblad by” behoort nie stilweg ’n nuwe ontledingspakket te magtig nie. ’n Plan wat gister goedgekeur is, behoort nie outomaties vandag se wesenlik veranderde diff te dek nie. Die koppelvlak behoort daardie grense sigbaar te maak.
Voorskoue verander hersiening in inspeksie
Kodehersiening is dikwels makliker wanneer mense die resultaat kan inspekteer eerder as om dit uit bronlêers af te lei. ’n Lewendige HTML-voorskou kan gebreekte spasiëring, ontbrekende toestande, ontoeganklike kontroles of ’n onbedoelde verandering in navigasie onthul wat ’n beoordelaar in ’n tekstuele diff kan miskyk.
Voorskoue is nie bewys van korrektheid nie. Hulle behoort langs toetse en bronhersiening te staan, nie dit te vervang nie. Maar hulle skep ’n gemeenskaplike voorwerp vir bespreking: ’n beoordelaar kan na ’n spesifieke skerm, toestand of interaksie verwys en terugvoer aan die voorgestelde verandering koppel.
Dit is veral waardevol wanneer nie-spesialiste deel van die hersiening is. ’n Produkbestuurder kan moontlik nie ’n raamwerkverandering beoordeel nie, maar kan die regte persoon wees om te bevestig dat die werkvloei met die vereiste ooreenstem. ’n Ontwerper kan ’n visuele regressie bekragtig. ’n Sekuriteitspesialis kan op toestemmings en datahantering fokus. Die agent-gesteunde werkruimte kan elke vraag na die persoon stuur wat die beste geplaas is om dit te beantwoord.
Diffs benodig konteks, nie net kleur nie
’n Bekende rooi-en-groen diff bly noodsaaklik, maar agent-gegenereerde veranderinge kan breed genoeg wees om ’n beoordelaar te oorweldig. Spanne behoort agente te vra om commits of veranderingsgroepe klein te hou, te verduidelik waarom elke belangrike lêer verander het en gegenereerde of verskafferlêers afsonderlik te identifiseer.
Nuttige hersieningsvrae sluit in:
- Watter gebruikerssigbare gedrag het verander?
- Watter lêers is slegs verander om die implementering te ondersteun?
- Watter aannames het die agent oor bestaande gedrag gemaak?
- Watter toetse is bygevoeg, gewysig of nie uitgevoer nie?
- Kan hierdie verandering toestemmings, dataretensie, fakturering of eksterne API’s beïnvloed?
Hierdie vrae verander hersiening van ’n vae versoek om “hierna te kyk” in ’n herhaalbare ondersoek. Dit help ook om ’n algemene mislukkingswyse bloot te lê: ’n oënskynlik aanvaarbare kenmerk wat gepaardgaan met ’n onvolledige toetsopdatering of ’n toevallige konfigurasieverandering.
Argiveer die redenasie wat saak maak
Om elke teken van elke modelgesprek te bewaar, is nie outomaties nuttig nie. Lang geskiedenisse kan duur wees om te stoor en moeilik wees om te deursoek, terwyl navorsing oor kontekssamedrukking waarsku dat opsommings belangrike inligting kan verloor. ’n Praktiese ouditspoor behoort dus besluitrelevante artefakte te bewaar eerder as om alles sonder onderskeid te stoor.
Behoud ten minste die versoek, goedgekeurde plan, finale diff, nutsmiddel- en toetsresultate, voorskou- of ontplooiingsverwysing, beoordelaars se besluite en enige toegestaande uitsondering. Indien ’n agent eksterne bronne gebruik of interne dokumente opgespoor het, teken die relevante bronverwysings aan, asook die punt waarop hulle die verandering beïnvloed het. Vir werk met ’n hoë risiko kan dit geregverdig wees om die volledige interaksie- en uitvoeringslog te behou.
Maak rekords manipulasie-opmerklik waar die belange dit vereis, en definieer retensiereëls voordat ’n krisis ontstaan. ’n Ouditspoor wat verdwyn wanneer ’n kanaal geargiveer word—of wat nie ’n gewysigde resultaat van die oorspronklike kan onderskei nie—sal nie ’n ernstige ondersoek ondersteun nie.
Wat dit vir loopbane in sagteware verander
Die vaardigheid wat na vore tree, is nie bloot om beter opdragte te skryf nie. Dit is om werk te ontwerp wat ’n ander persoon kan inspekteer en vertrou. Ontwikkelaars sal gemaklik moet wees daarmee om aanvaardingskriteria te spesifiseer, take op te breek, diffs op skaal te hersien, betekenisvolle toetse te bou en te besluit waar ’n agent moet stop en vra.
Produk- en ontwerppersoneel sal ’n groter rol speel in die hersiening van voorskoue en die opheldering van bedoeling. QA-ingenieurs kan help om goedkeuringshekke en gevalle van mislukking te definieer. Ingenieursbestuurders sal deurset moet meet sonder om onsigbare risiko-neming te beloon. Tegniese skrywers en bedryfspesialiste kan bydra deur besluite, uitsonderings en loopboeke duursaam te maak.
Een nuttige oefening is om ’n roetinekenmerk te neem en die bewysketting daarvan te karteer: versoek, plan, tak, diff, toetse, voorskou, goedkeuring, vrystelling en terugrol. Vra dan waar ’n toekomstige spanmaat gedwing sou word om te raai. Elke raaiskoot is ’n kandidaat vir ’n beter werkruimte, ’n duideliker toestemming of ’n meer duursame rekord.
’n Eenvoudige bedryfsreël
Laat agente vinnig beweeg binne ’n sigbare, omkeerbare baan. Gee hulle ’n gedefinieerde werkruimte, beperk sensitiewe handelinge, vereis goedkeuring by betekenisvolle grense, koppel bewyse aan die verandering en bewaar die finale besluit. Die doel is nie om outomatisering te vertraag totdat dit soos handkodering lyk nie. Dit is om spoed met aanspreeklikheid versoenbaar te maak.
In agentondersteunde ontwikkeling is die beste medewerker nie die stelsel wat in isolasie die meeste kode lewer nie. Dit is die stelsel waarvan die werk verstaan, bevraagteken, goedgekeur, ongedaan gemaak en uit geleer kan word.
