Sandbox do code review i sprawdzania PR: udowodnij, że poprawka działa, zanim ją zatwierdzisz

Diff pokazuje, co poprawka twierdzi, że robi. Nie pokazuje, czy błąd naprawdę zniknął, czy nowa gałąź if kiedykolwiek się wykona ani czy podbicie zależności nie psuje importu przy czystej instalacji. Recenzenci o tym wiedzą, dlatego tyle review kończy się słowami „LGTM, o ile testy przejdą”.

Przy poprawkach pisanych przez AI ta luka rośnie. Model szybko produkuje wiarygodnie wyglądający kod, a wiarygodnie wyglądający to dokładnie taki, który prześlizguje się obok zmęczonego recenzenta. Tanie rozwiązanie: uruchomić zmianę, zanim ktokolwiek ją zatwierdzi — tam, gdzie niczego nie zepsuje.

Sprawdzenie: base, head, testy

Najbardziej przekonujący dowód, jaki może dać poprawka, to odtworzenie, które pada na starym kodzie i przechodzi na nowym. Sandbox zamienia to w skrypt na 20 linii. To microVM Firecracker z Pythonem 3.12, Node.js 22, git i curl, uruchamiana w około 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 to fragment z raportu błędu. Jeśli kończy się kodem różnym od zera na base i zerem na head, poprawka naprawia to, co deklaruje. Opublikuj tę linię razem z podsumowaniem testów jako komentarz w pull requeście, a recenzent zaczyna od faktów.

Zestaw testów działa jako zadanie w tle, bo pojedyncze polecenie synchroniczne zatrzymuje się po 55 sekundach. TTL 30 minut ogranicza, ile może kosztować zawieszony przebieg.

Agenci review, którzy uruchamiają kod

Ten sam pomysł działa dla recenzenta AI. Podłączony przez serwer MCP agent ma narzędzia sandboxów: utworzyć sandbox, wykonać polecenie, wysłać i pobrać pliki. Zamiast pisać „to może zepsuć zgodność z Pythonem 3.8”, pobiera gałąź, uruchamia kod i cytuje traceback — albo informuje, że wszystko jest w porządku.

Daj takiemu agentowi limit wydatków i token tylko do odczytu oraz zdecyduj, które narzędzia może wywoływać bez pytania. W zabezpieczeniach MCP każde narzędzie jest opisane według poziomu ryzyka.

Która taryfa

Sandboxy efemeryczne są rozliczane za sekundę z minimum 60 sekund. Jeśli recenzent chce wracać do tego samego środowiska przez kilka dni, utwórz je jako persistent: zachowuje dysk do 30 dni i jest rozliczane za każdą rozpoczętą godzinę, więc sandbox standard trzymany na dwudniowe review kosztuje około $3.17. Usuń go po scaleniu pull requestu.

Limity, które warto znać

• Dwa polecenia naraz na konto. W zupełności wystarcza na review, które idą jedno po drugim. Jeśli sprawdzasz dziesiątki pull requestów jednocześnie, ustawią się w kolejce.
• Brak portów przychodzących. Nie otworzysz aplikacji w przeglądarce. Uruchom ją w środku i przetestuj przez curl localhost z drugiego polecenia.
• Brak Dockera w środku. Testy, które uruchamiają kontenery, należą na runner na VPS.
• Ruch wychodzący jest otwarty. Dzięki temu działa pip install. Nie wkładaj do sandboxa niczego, czego nie dałbyś autorowi poprawki.

Jak zacząć

Nowe konta dostają $1 czasu sandboxów, co wystarcza na ponad sto przebiegów review na taryfie standard. Strona sandboxów pokazuje taryfy, dokumentacja SDK każdą użytą wyżej metodę, a SDK dla Pythona w 5 minut konfigurację.

Powiązane: izolowane przebiegi testów CI dla całego pipeline'u i sandbox dla agentów AI dla agentów, którzy ten kod w ogóle piszą.