Grensedom, vareiterasjon

Alle organisasjoner som bygger en intern agentisk-kodingsplattform, treffer den samme veggen. Modellen du stoler på for å vurdere endringer, er den du ikke har råd til å skrive alle sammen. Dette notatet beskriver leveransemønsteret vi kjører på Borge Labs for å løse det: grensemodeller ved vurderingsportene, lavere kostnad for iterasjonsbaner koblet til piloter, eksplisitt menneskelig samtykke før arbeidet starter, og to menneskelige leveringsporter. Den er liten nok til å lese på fem minutter og konkret nok til å kopiere.

Formen

Én arbeidskø på smia du allerede har i drift. Problemene er grensesnittet, tilstandsmaskinene er etiketter, og samtykke er eksplisitt: et problem er urørlig inntil et menneske har merket det som klart. En konduktør leder hvert problem gjennom en fast ring:

• Plan den kraftigste modellen som er tilgjengelig. Planen er at en annen modell kan utføre planen ordrett: filer, kommandoer, akseptansekriterier, levende verifikasjonssteg.
• Menneskeport nummer en: En person godkjenner spesifikasjonen med en etikett. Ingenting kan bygges uten den.
• Bygg på en motor som passer til arbeidet. Planleggeren merker hver billett med vanskelighetsgrad. Sterkere byggere håndterer den etablerte produksjonsveien; råvare-API og lokale åpne vektbaner er koblet til planleggertaggede lette nivåer bak en eskaleringsbane.
• Omtale Det gjøres normalt av en annen modell enn den som bygger, igjen på grunnlag av skjønn. Lavere kostnad for pilotbygg krever en ny vurdering av en annen modell før godkjenning; hvis den modellen ikke er tilgjengelig eller bruken er oppbrukt, blir porten registrert eksplisitt.
• Menneskeport nummer to: En person slår sammen forespørselen om sammenslåing. På våre produktrepositorier er sammenslåing utrulling.
• Bekreft live og legge ved beviset til saken før den lukkes. En endring som ikke har blitt observert i produksjon, blir ikke gjort.

De to reglene som beskytter økonomien

Først: ett forsøk per nivå, deretter eskalering. I den billige banen, når en build feiler, flyttes billetten opp i hierarkiet med funnene vedlagt, for å bli gjenoppbygget av en sterkere motor. Den itererer aldri mot den dyre revieweren, fordi en svak bygger som ping-pong'er med en frontier reviewer koster mer enn den billige builden som ble spart. For det andre: risiko overgår vanskelighet. Alt som berører auth, fakturering, hemmeligheter, migrasjon, deploy eller personlige data blir alltid bygget av den sterkeste motoren fra en fullt godkjent spec, uansett hvor 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.

Grensen som gjør det trygt å automatisere

Agentenes tilgang er begrenset til en troverdig vert. Veien til produkt og infrastruktur går via skoperte botidentiteter; den kan også oppdatere køproblemer og sende driftsrelaterte varsler. Kluster-tilgang er lesebeskyttet, produktdata lagres ikke, og tilgang til observabilitet er separat skopert og auditert. Materiale som sendes til kodemodeller må fortsatt være syntetisk eller sanert. Denne leveranseprosessen krever en menneskelig pull-request-fusjon før utrulling. Porten er sterkest når smedbeskyttelser også nekter direkte botpush, og disse eksterne kontrollene må verifiseres, ikke utledes fra en prompt. Prompts er instruksjoner; credentials er grenser. Resultatet er en revisjonslogg som endringsstyringsprosessen din allerede forstår: sak, godkjent spesifikasjon, pull request, adversarial cross-model review, menneskelig fusjon, live verifisering.

Den samme delingen hjelper også med dataoppbevaring. Modeller for domstolsavgjørelser mottar kode, godkjente spesifikasjoner og bevisst renset driftsbevis. Hvis materialet må forbli innenfor en jurisdiksjon, må du bare rute det til en godkjent tjenesteleverandør innenfor jurisdiksjonen eller til en lokal åpen kildekode-modell på maskinvare du kontrollerer.

Hvis du bygger en intern plattform

De fleste plattformene for intern agentisk koding konvergerer mot den samme listen over deler: felles arbeidsområder for innbyggerutviklere og profesjonelle utviklere, et bibliotek med ferdigheter eller prompt, en LLM-port, en MCP-katalog og en asfaltert vei til produksjon. Dette mønsteret faller inn i den verdenen uten ny infrastruktur. Køkøen er billettsystemet ditt. Endringsgrensen og de to leveringsgatene er endringsstyringen din. Byggestigene er modellruter i porten du allerede driver. Grensen for legitimasjon er en arbeidsområdeprofil. Det mønsteret tilfører er disiplinen som gjør plattformen rimelig og gjennomførbar samtidig: dømmekraft der det betyr noe, iterasjon der det er billig, og en eskaleringsstige slik at feil koster øre i stedet for tillit.

Status

Dette er ikke et mønster for et hvitt papir. Ringen som er beskrevet her, har kjørt i vår egen infrastruktur og levert reviderte, verifiserte endringer i våre egne produkter, med den sterkeste tilgjengelige grensemodellen i porten og de rimeligste banene som er pilotert under. To byggesteiner er åpen kildekode i dag: ai-team, den chat-native spesifikasjonen og interessentlaget. ai-dev-team, den overvåkede utførelsesharnessen med en ærlig benchmark-historie. Selve lederen er noen få hundre linjer med skall og promptfiler over vanlig forge, som er poenget: verdien er formen, ikke programvaren.

Bygge noe slikt internt? Vi har kjørt hele sløyfen, inkludert feilmodus, og vi liker å sammenligne notater. Ta kontakt.