Vibe-kodering het verander wie ’n toepassing wat werkend lyk, kan vervaardig. ’n Aanwysing kan skerms genereer, ’n API koppel en ’n geloofwaardige werkvloei saamstel voordat ’n tradisionele ingenieurspan sy eerste ontwerphersiening afgehandel het.

Daardie spoed skep ’n nuwe aanstellings- en afleweringsprobleem: ’n demonstrasie is nie meer sterk bewys dat sagteware goed is nie. Werkgewers sal toenemend ’n moeiliker vraag vra: kan hierdie KI-geboude stelsel korrek optree wanneer insette deurmekaar is, afhanklikhede misluk, gebruikers handelinge herhaal en die onderliggende model verander?

Die antwoord sal kom van ’n gehaltebalk wat minder soos visuele afronding en meer soos gedissiplineerde sagtewareverifikasie lyk. Die mense wat uitstaan, sal nie bloot wys wat ’n KI-koderingshulpmiddel vervaardig het nie. Hulle sal wys hoe hulle dit getoets het, wat dit nie veilig kan doen nie, en hoe hulle weet dat ’n verandering niks anders gebreek het nie.

’n Maatstaf is bewys, nie ’n ranglystelling nie

Oopbronmaatstawwe vir koderingsagente bied nuttige vertrekpunte, maar hulle meet verskillende vermoëns. SWE-bench gebruik werklike GitHub-kwessies en bewaarplekkiekse, wat dit relevant maak vir instandhoudingswerk. Terminal-Bench toets opdragreëlinteraksie. Ander gelyste maatstawwe, insluitend SlopCodeBench en ProgramBench, fokus op verskillende aspekte van gegenereerde kode en agentgedrag.

Daardie maatstawwe kan help om hulpmiddels te vergelyk of ’n basislyn daar te stel, maar werkgewers behoort versigtig te wees om enige enkele telling as bewys van produksiegereedheid te beskou. ’n Model wat bewaarplekkwessies oplos, kan steeds onveilige magtigingslogika lewer. ’n Agent wat terminaaltake voltooi, kan dalk nie toestand oor ’n lang werkvloei heen behou nie. ’n Gepoleerde webtoepassing kan ’n gelukkige-pad-demonstrasie slaag terwyl dit hertoeppogings of duplikaatbetalings verkeerd hanteer.

’n Geloofwaardige portefeulje of interne hersiening behoort dus ’n taakspesifieke evaluasiestel in te sluit. Die stel kan verteenwoordigende foutverslae, normale gebruikersreise, verkeerd geformateerde insette, toestemmingsgrense, afhanklikheidsfoute en voorheen reggestelde regressies bevat. Elke geval behoort ’n uitdruklike verwagte resultaat te hê, nie bloot ’n skermskoot wat reg lyk nie.

Die minimum toetsstel vir KI-geboude sagteware

Vir ’n klein toepassing kan ’n nuttige gehaltestel sonder ’n uitgebreide navorsingslaboratorium saamgestel word:

  • Aanvaardingstoetse: verifieer die gebruikerssigbare gedrag vir die belangrikste werkvloeie, insluitend suksesvolle en onsuksesvolle uitkomste.
  • Eenheids- en integrasietoetse: kontroleer besigheidsreëls in isolasie en bevestig dat databasisse, API’s, toue en verifikasie saamwerk soos bedoel.
  • Negatiewe toetse: stuur ontbrekende, verkeerd geformateerde, te groot, gedupliseerde en ongemagtigde insette. KI-gegenereerde kode lyk dikwels die sterkste op die pad wat in die aanwysing gewys word, en daarom is die ongevraagde paaie belangrik.
  • Regressietoetse: verander elke ontdekte defek in ’n permanente toets. ’n Groen demonstrasie ná ’n regstelling is nie genoeg as dieselfde fout in die volgende gegenereerde verandering kan terugkeer nie.
  • Sekuriteitskontroles: toets toegangsbeheer, geheimhantering, verdediging teen inspuiting, afhanklikheidskwesbaarhede, en of onbetroubare inhoud werktuigoproepe of bevoorregte handelinge kan beïnvloed.
  • Bedryfskontroles: verifieer tydverstreke, hertoeppogings, idempotensie, aantekening, waarskuwings en veilige gedrag wanneer ’n afhanklikheid nie beskikbaar is nie.

Dit stem grootliks ooreen met die QA-ingenieursdenkwyse wat in Stack Overflow se beskrywing van ’n agentiese sagteware-ontwikkelingslewensiklus uiteengesit word. Die belangrike verskuiwing is kultureel: gehalteversekering is nie ’n finale inspeksie nadat ’n KI die kode geskryf het nie. Dit is die struktuur wat vinnige generering veilig genoeg maak om te gebruik.

Toets die orkestrasie, nie net die uitvoer nie

Wanneer sagteware ’n KI-agent insluit, is gewone toepassingstoetse noodsaaklik maar onvoldoende. Die stelsel kan misluk omdat die model ’n versoek verkeerd verstaan het, maar dit kan ook misluk omdat die omliggende orkestrasie konteks verloor het, ’n hulpmiddel twee keer geroep het, verkeerd geformateerde gestruktureerde uitvoer aanvaar het, of nooit beëindig is nie.

Die digest se aanbevole regressiegebiede vóór ontplooiing is ’n praktiese kontrolelys: konteksverlies, werktuig-idempotensie, aanwysinginspuiting, gestruktureerde uitvoer, niebeëindiging, gronding van herwinning en toestandherlaai. Dit is toetsbare ingenieurseienskappe.

Byvoorbeeld, ’n toets kan dieselfde versoek twee keer uitvoer en bevestig dat die tweede poging nie ’n duplikaatbestelling skep nie. ’n Ander kan ’n agent halfpad deur ’n werkvloei onderbreek, dit herbegin en verifieer dat dit uit ’n geldige toestand hervat eerder as om ’n onomkeerbare handeling te herhaal. ’n Herwinningstoets kan vereis dat die stelsel slegs inligting uit ’n goedgekeurde bronstel aanhaal of terugstuur. ’n Gestruktureerde-uitvoertoets kan ’n ongeldige antwoord voorsien en bevestig dat die toepassing dit veilig verwerp eerder as om dit stilweg as geldige data te hanteer.

Langlopende en multi-agentstelsels benodig besonder duidelike mislukkingsrekords. Navorsers werk aan geoutomatiseerde mislukkingsattribusie omdat dit moeilik kan wees om vas te stel watter agent ’n mislukking veroorsaak het en op watter punt in ’n lang interaksieketting. In praktiese terme behoort spanne werktuigoproepe, insette, uitsette, modelweergawes, tydstempels, toestandsoorgange en finale besluite in ’n privaatheidsbewuste ouditspoor te bewaar. Sonder daardie bewyse sê ’n rooi toets vir jou dat iets misluk het, maar nie waar om met die regstelling te begin nie.

Reproduceerbaarheid sal ’n loopbaanvoordeel word

KI-gegenereerde kode is veranderlik. ’n Heruitvoering kan ’n ander implementering lewer; ’n modelopdatering kan gedrag verander; ’n diensverskafferonderbreking kan roetering of latensie verander. Werkgewers sal dus kandidate waardeer wat evaluerings herhaalbaar kan maak.

Dit beteken dat modelmomentopnames waar moontlik vasgepen word, aanwysings en konfigurasie aangeteken word, willekeurigheid beheer word wanneer die platform dit toelaat, en veelvuldige proewe uitgevoer word vir take waarvan die uitkomste wissel. Die digest wys spesifiek op vasgepen modelmomentopnames, lae of nul temperatuur waar beskikbaar, en vertrouensbegrensde CI/CD-hekke as nuttige beskermingsmaatreëls.

’n Praktiese verslag behoort ten minste drie resultate te onderskei:

  1. Slaagkoers: hoeveel gevalle geslaag het.
  2. Konsekwentheid: hoe dikwels dieselfde geval oor herhaalde lopies slaag.
  3. Erns: of mislukkings kosmeties, ongerieflik, dataskadelik, sekuriteitsrelevant is, of ’n onveilige eksterne handeling kan veroorsaak.

’n Stelsel wat 19 uit 20 laerisiko-formateringskontroles slaag, is nie noodwendig beter as een wat 18 uit 20 gevalle slaag nie, maar nooit ’n magtigingsgrens oorsteek nie. Die gehaltevlak moet mislukkings volgens hul gevolge weeg.

Menslike hersiening moet risiko teiken, nie elke reël nie

Die doel van beter outomatisering is nie om iemand te dwing om elke teken wat deur ’n KI geproduseer word, weer te lees nie. Dit is om menslike aandag te rig op die besluite wat toetse nie volledig kan besleg nie.

Hersieners moet fokus op verifikasie en magtiging, databewaring, finansiële of kontraktuele handelinge, privaatheid, migrasies, foutherstel, derdepartytoestemmings en veranderinge wat die stelsel se eie evalueringsharnas beïnvloed. Vir ’n agent moet hulle ook hersien watter nutsmiddels dit mag oproep, tot watter data elke nutsmiddel toegang het, en of goedkeuring vereis word voordat ’n onomkeerbare handeling uitgevoer word.

Sigbare verskille, goedkeuringswerkvloeie, geargiveerde gesprekke en ouditlogboeke—kenmerke wat in Slack Code se beskrywing van samewerkende KI-kodering beklemtoon word—dui op ’n breër verwagting: die geskiedenis van hoe sagteware gemaak is, sal saak maak. ’n Hersiener moet die versoek kan verstaan, die gegenereerde verandering kan inspekteer, die toetsbewyse kan sien en kan vasstel wie die ontplooiing goedgekeur het.

Daardie rekord is nie ter wille van burokrasie alleen nie. Dit maak ’n indrukwekkende demonstrasie onderskeibaar van ’n beheerde verandering wat iemand anders kan onderhou.

Wat om in ’n portefeulje of onderhoud te plaas

Vir kandidate is die sterkste demonstrasie ’n klein stelsel met ’n doelbewus sigbare gehalteverhaal. Sluit die bewaarplek, opstellingsinstruksies, argitektuurnotas, toetsopdragte, verteenwoordigende toetsgevalle, bekende beperkings en ’n kort mislukkingsverslag in. Toon een of twee foute wat gevind en in regressietoetse omskep is. Verduidelik watter model of koderingagent gebruik is sonder om die nutsmiddel as die outeur van die ingenieursbesluite voor te stel.

As die toepassing ’n agent gebruik, dokumenteer die nutsmiddeltoestemmings, toestandsmodel, herprobeerbeleid, beëindigingsvoorwaarde en menslike goedkeuringspunte. As dit herwinning gebruik, wys hoe bronne gekies word en wat gebeur wanneer bewyse ontbreek. As dit eksterne dienste oproep, demonstreer tydverstreke en gedrag by duplikaatversoeke.

Moenie betroubaarheid op grond van ’n enkele suksesvolle opname beweer nie. ’n Kontroleerbare bewering klink eerder soos: “Oor 30 aangetekende lopies van hierdie 12 scenario’s het die stelsel in 28 aan die aanvaardingskriteria voldoen; die twee mislukkings het dubbelsinnige datuminvoer behels, en albei is gedokumenteer.” Die getal self is minder belangrik as die metode, die grense en die eerlikheid oor wat nog nie getoets is nie.

Die nuwe definisie van vinnig

KI verlaag die koste om ’n eerste weergawe te vervaardig. Dit verwyder nie die koste om te weet of daardie weergawe vertroue verdien nie. Trouens, vinniger generering kan evaluering belangriker maak, omdat meer onhersiene veranderinge tussen ontplooiings kan ophoop.

Die professionele persoon ná die era van vibe-kodering sal aan die hand van die siklus beoordeel word: definieer gedrag, genereer of wysig kode, toets realistiese en teenstrydige gevalle, inspekteer hoërisikobesluite, teken mislukkings aan en verbeter die stelsel sonder om bewyse te verloor. Maatstawwe kan help om vermoë te vergelyk. QA-praktyke bepaal of daardie vermoë betroubare sagteware word.

Die gehaltevlak is dus nie “Kan jy ’n toepassing met KI maak?” nie. Dit is “Kan jy bewys wat die toepassing doen, bespeur wanneer dit ophou om dit te doen, en die grense ontwerp wat keer dat ’n mislukking ’n insident word?”