Hoppa till huvudinnehåll

Del 8: Gör det till en teamstandard

Allt i de sju första delarna fungerar för en enda utvecklare. I det ögonblick ett team är inblandat uppstår ett extra felmönster: harnessen börjar drivas iväg. En persons regelfil säger en sak, en annans säger något annat, agentbeteendet blir irreproducerbart i teamet och disciplinen eroderar tyst. Den här delen handlar om att göra arbetsflödet till en gemensam, hållbar standard.

Den grundläggande principen att ha i åtanke: AI förstärker den ingenjörskultur den landar i. Ett team med starka tester, tydliga standarder och sund granskning får dramatiskt mer ut av dessa verktyg. Ett team utan sådana blir snabbare på att producera problem. Poängen med att standardisera är att göra den goda kulturen till vägen med minst motstånd.

Behandla harnessen som kod​

Regelfilerna, systempromptarna, evalueringssviternas och skill-biblioteken är inte personlig konfiguration — de är delad infrastruktur. Behandla dem precis som kod:

  • Versionshantera dem med projektet.
  • Granska dem i pull requests, som vilken annan ändring som helst.
  • Tilldela namngivna ägare, så de underhålls med avsikt snarare än att förfalla.

Utan detta beter sig varje utvecklares agent lite olika och ingen kan reproducera någon annans resultat.

Gate:a på evalueringen, inte demon​

En fungerande demo bevisar att en agent kan lyckas en gång. En godkänd evalueringssvit bevisar att den lyckas tillförlitligt. De två är inte samma sak, och att leverera på styrkan av en demo är hur opålitliga agenter når produktion.

Gör evalueringstäckning till ett förvillkor för leverans, på samma sätt som du gate:ar en tjänst på testtäckning. Men en evaluering utan ett tydligt rubric mäter ingenting — definiera därför vad du poängsätter:

  • Uppgiftsframgång
  • Verktygsanvändningskvalitet
  • Trajektorieöverensstämmelse
  • Hallucinationsfrekvens
  • Svarskvalitet

En CI-gate gör det verkligt:

# ci: block merge if the agent's eval suite regresses
agent-evals:
  run: eval-suite --rubric rubric.yaml --min-score 0.9
  on: [pull_request]
  required: true

Omforma kodgranskning för genererad kod​

Genererad kod behöver samma granskning som mänsklig kod, eller mer — och granskare behöver känna till dess specifika felmönster. Träna dem att leta efter hallucinerade beroenden, tunn felhantering och korrekthetsluckor som ser bra ut vid en snabb titt (del 5). Justera granskningschecklistan mot dessa mönster snarare än att återanvända den gamla mänsklig-kod-checklistan oförändrad.

Rita prototype/produktion-gränsen explicit​

Snabb, lös utforskning och disciplinerat produktionsarbete är båda giltiga — men bara när alla vet vilket som är vilket. Gör gränsen explicit:

  • Vilka repos är produktion kontra sandlåda.
  • Vilka grenar kräver full disciplin.
  • Vilka miljöer en agents utdata kan nå.

Team som lämnar detta otydligt producerar prototyper som levereras av misstag. En skriven gräns håller utforskning snabb och produktion säker på samma gång.

Bygg harnessen en gång, förfina den många gånger​

Återanvändbara promptar, skill-bibliotek, verktygsanslutningar och evalueringsharnesses förstärks över projekt. De team som får ut mest av AI-utveckling är de som bygger denna delade harness en gång och fortsätter förbättra den, snarare än att varje person bygger om sin egen från grunden. Behandla den som infrastruktur: dokumenterad, underhållen, avsiktligt förbättrad.

Anställ och befordra för omdöme​

I takt med att implementering blir billigare flyttar flaskhalsen till specifikation, utvärdering och arkitekturellt omdöme. De mest värdefulla ingenjörerna under de kommande åren är de som kan dirigera agenter väl — inte de som kan skriva mest kod. Spegla det i hur du anställer, nivåsätter och utvecklar människor: väg specifikationsfärdighet, utvärderingsstränghet och systemdesign tyngre än rå implementeringshastighet.

De starkaste uppläggnen är hybrida av design: människor sätter riktning, agenter implementerar, och tydliga överlämningsprotokoll styr gränsen. Kodgranskning, jour och teamstruktur utvecklas alla för att behandla agenter som deltagare, inte bara verktyg.

Sätt upp ditt eget arbetsflöde​

  • Flytta regelfiler, promptar, evalueringar och skills till repot; kräv PR-granskning för ändringar.
  • Tilldela en ägare för den delade harnessen.
  • Lägg till en CI-gate som blockerar sammanslagningar när evalueringssviten regrederar under ett tröskelvärde.
  • Skriv en ensides granskningsguide för felmönster i genererad kod.
  • Dokumentera prototype-kontra-produktion-gränsen: repos, grenar, miljöer.
  • I ditt nästa anställningsrundor, lägg till en specifikations-och-evalueringsövning, inte bara ett kodtest.

Källa: The New SDLC With Vibe Coding (Google) — https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding