Sandbox för kodgranskning och PR-kontroller: bevisa att en patch fungerar innan du godkänner den

En diff visar vad en patch påstår att den gör. Den visar inte om buggen verkligen är borta, om den nya grenen i en if någonsin körs eller om uppgraderingen av ett beroende förstör importen vid en ren installation. Granskare vet det, och därför slutar så många granskningar med ”LGTM, förutsatt att testerna går igenom”.

Med AI-skrivna patchar blir glappet större. En modell producerar snabbt trovärdig kod, och trovärdig är precis den sort som slinker förbi en trött granskare. Den billiga lösningen är att köra ändringen innan någon godkänner den – någonstans där den inte kan skada något.

Kontrollen: base, head, tester

Det mest övertygande bevis en patch kan ge är en reproduktion som misslyckas på den gamla koden och går igenom på den nya. En sandbox gör det till ett skript på 20 rader. Det är en Firecracker-microVM med Python 3.12, Node.js 22, git och curl, startad på ungefär en sekund:

import os
from eqvps import Sandbox

REPO, BASE, HEAD = os.environ["REPO_URL"], os.environ["BASE_SHA"], os.environ["HEAD_SHA"]

def repro(sb, ref):
    sb.exec(f"cd /root/app && git checkout -q {ref}", timeout=55)
    return sb.exec("cd /root/app && python3 /root/repro.py", timeout=55).exit_code

with Sandbox.create(tariff="standard", ttl=1800) as sb:
    sb.exec(f"git clone -q {REPO} /root/app", timeout=55)
    sb.exec("cd /root/app && pip install -q -r requirements.txt", timeout=55)
    sb.upload("/root/repro.py", open("repro.py").read())
    before, after = repro(sb, BASE), repro(sb, HEAD)
    tests = sb.exec("cd /root/app && python3 -m pytest -q", background=True).wait()
    print(f"repro on base: {before}, on head: {after}; tests: {tests.state}, exit {tests.exit_code}")

repro.py är kodsnutten från buggrapporten. Avslutas den med en kod skild från noll på base och med noll på head, fixar patchen det den påstår. Lägg upp den raden plus testsammanfattningen som en kommentar på pull requesten, så börjar granskaren med fakta.

Testsviten körs som bakgrundsuppgift eftersom ett enskilt synkront kommando stoppar efter 55 sekunder. TTL på 30 minuter begränsar hur länge en körning som hängt sig kan kosta pengar.

Granskningsagenter som kör kod

Samma idé fungerar för en AI-granskare. Ansluten via MCP-servern har en agent sandboxverktyg: skapa en sandbox, köra ett kommando, ladda upp och ner filer. I stället för att skriva ”det här kan förstöra kompatibiliteten med Python 3.8” checkar den ut branchen, kör koden och citerar traceback – eller rapporterar att allt är i sin ordning.

Ge en sådan agent ett utgiftstak och en skrivskyddad token, och bestäm vilka verktyg den får anropa utan att fråga. MCP-skydd listar varje verktyg efter risk.

Vilken tariff

Tillfälliga sandboxar debiteras per sekund med minst 60 sekunder. Vill en granskare återvända till samma miljö under ett par dagar, skapa den då som persistent: den behåller sin disk i upp till 30 dagar och debiteras per påbörjad timme, så en standard-sandbox som hålls för en tvådagarsgranskning kostar ungefär $3.17. Radera den när pull requesten är mergad.

Gränser värda att känna till

• Två kommandon åt gången per konto. Gott om för granskningar, som körs efter varandra. Kontrollerar du dussintals pull requests samtidigt hamnar de i kö.
• Inga inkommande portar. Du kan inte öppna appen i en webbläsare. Starta den inuti och testa den med curl localhost från ett andra kommando.
• Ingen Docker inuti. Tester som startar containrar hör hemma på en runner på en VPS.
• Utgående internet är öppet. Det är det som får pip install att fungera. Lägg inget i sandboxen som du inte skulle ge till patchens författare.

Kom igång

Nya konton får $1 i sandboxtid, vilket räcker till mer än hundra granskningsomgångar med tariffen standard. Sandboxsidan visar tarifferna, SDK-referensen varje metod som används ovan, och Python-SDK på 5 minuter installationen.

Relaterat: isolerade CI-testkörningar för hela pipelinen, och sandbox för AI-agenter för agenterna som skriver koden från början.