Grensedom, vareiterasjon

Kvar organisasjon som bygger ein intern agentisk-kodingsplattform, møter den same veggen. Modellen du stoler på for å vurdere endringar, er den du ikkje har råd til å skrive alle endringane i. Dette notatet beskriv leveransemønsteret vi køyrer på Borge Labs for å løyse det: frontier-modellar ved vurderingsgatene, billegare iterasjonsløp kopla til pilotar, eksplisitt samtykke frå menneske før arbeidet startar, og to menneskelege leveranseportar. Det er lite nok til å lese på fem minutt og konkret nok til å kopiere.

Forma

Ein arbeidskø på smia du allereie har i drift. Problem er grensesnittet, tilstandsmaskin er statusen, og samtykke er eksplisitt: eit problem er urørleg fram til eit menneske har merkt det som klart. Ein konduktør fører kvar sak gjennom ein fast ring:

• Plan den kraftigaste modellen som er tilgjengeleg. Planen er at ein annan modell kan utføra planen ordrett: filer, kommandoar, akseptansekriterium, steg for verifisering.
• Menneskeport nummer ein: Ein person godkjenner spesifikasjonen med ein etikett. Ingenting blir bygd utan han.
• Bygg på ein motor som er tilpassa arbeidet. Planleggaren merkar kvar billett med vanskegrad. Sterkare byggjarar handterer den etablerte produksjonsvegen; vare-API og lokale opne vektbaner er kopla til planleggar-merka lette etasjar bak ein eskaleringsveg.
• Omtale I motstrid, normalt av ein annan modell enn byggjaren, igjen på grensevurdering. Lågare kostnad pilotbygg ber om ei ny grensevurdering før godkjenning; dersom den vurderaren ikkje er tilgjengeleg eller bruken er oppbrukt, blir den nedgraderte porten registrert eksplisitt.
• Menneskeport nummer to: Ein person slår saman endringane i ein pull request. På produktrepositoria våre er merge deploy.
• Verifiser live og legg beviset til saka før ho blir lukka. Ei endring som ikkje har blitt observert i produksjon, blir ikkje gjort.

Dei to reglane som vernar økonomien

Først: ein sjanse per nivå, så eskalering. I den billige banen, når ein build feiler, så går billetten opp i nivå med funn vedlagt, for å bli bygd på nytt av ein sterkare motor. Den itererer aldri mot den dyre revieweren, fordi ein svak byggar som ping-pongar med ein frontier reviewer kostar meir enn den billige builden som blir spart. Sekund: risiko overgår vanskelighet. Alt som berører auth, fakturering, hemmeligheter, migrasjon, deploy eller persondata blir alltid bygd av den sterkaste motoren fra ein fullt godkjent spec, uansett kor liten diff-en ser ut.

Grunnen til at splitting fungerer i det hele tatt er at bygg og review har helt forskjellige tokenprofiler. Bygg brenner tokens i sløyfen: utforsk, rediger, kjør tester, les feil, fiks, gjenta. Review leser en ferdig diff mot en spesifikasjon én gang. Så frontier-billetten skalerer med størrelsen på endringen, ikke med innsatsen det tok å produsere den. I vårt oppsett anslår vi at vurderingsandelen er omtrent en femtedel til en tredjedel av hva frontier-bygde endringer ville kostet; vi måler det per bane og vil publisere tallene fremfor vibbene.

Grensa som gjer det trygt å automatisera

Agentane lever på ein sertifikat-bunden vert. Vegen til produkt og infrastruktur går via git gjennom skopte bot-identitetar; dei kan òg oppdatera kø-saker og senda drifts-varsel. Kluster-tilgang er berre lese-tilgang, produktdata er ikkje montert, og tilgang til observabilitet er skopte og auditerte kvar for seg. Materiale som blir sendt til kodemodellar må framleis vera syntetisk eller reinsa. Denne leveringsprosessen krev ein menneskeleg pull-request-merge før deploy. Porten er sterkast når smed-vern òg nektar direkte bot-push, og desse eksterne kontrollane må stadfestast heller enn å bli inferert frå ein prompt. Prompts er instruksar, sertifikat er grenser. Resultatet er ein revisjonslogg som endringsstyringsprosessen din allereie forstår: sak, godkjend spesifikasjon, pull request, adversariell kryss-modell-gjennomgang, menneskeleg merge, live verifisering.

Den same delinga hjelper med databusetnad. Modellar for domfelling får kode, godkjende spesifikasjonar og bevisst reinsa driftsbevis. Der materiale må bli verande innanfor ein jurisdiksjon, send det berre til ein godkjend leverandør innanfor jurisdiksjonen eller til ein lokal modell på maskinvare du kontrollerer.

Dersom du bygger ein intern plattform

Dei fleste plattformene for intern koding konvergerer mot den same lista over delar: delte arbeidsområde for borgarutviklarar og profesjonelle utviklarar, eit bibliotek med ferdigheiter eller promptar, ein LLM-port, ein katalog med MCP-ar, og ein asfaltert veg til produksjon. Dette mønsteret fell inn i den verda utan ny infrastruktur. Køkøen er billettsystemet ditt. Endringsgrensa og dei to leveransegrensene er endringsleiinga di. Byggjetrinna er modellruter i porten du allereie driv. Grensa for sertifisering er ein arbeidsprofil. Det mønsteret tilfører er disiplinen som gjer plattforma både rimeleg og oversiktleg: dømmekraft der det er viktig, iterasjon der det er billig, og ei eskaleringstrapp slik at feil kostar penniar i staden for tillit.

Status

Dette er ikkje eit kvitpapirmønster. Ringen som er skildra her, har gått i vår eiga infrastruktur og levert reviderte, verifiserte endringar i våre eigne produkt, med den sterkaste tilgjengelege grensemodellen i porten og dei billegaste køyrevegane som er pilotert under. To byggjesteinar er i dag opne kjeldekode: ai-team, det chat-native grensesnittet og interessentlaget. ai-dev-team, den overvaka eksekveringsharnessen med ei ærleg benchmark-historie. Sjølve leiaren er nokre hundre linjer med shell- og promptfiler over plain forge, som er heile poenget: verdien er forma, ikkje programvaren.

Bygga noko slikt internt? Me har gått gjennom heile sløyfa, inkludert feilmodi, og me likar å samanlikna notatar. Ta kontakt.