Sandbox para revisión de código y comprobaciones de PR: demuestra que un parche funciona antes de aprobarlo

Un diff muestra lo que un parche afirma hacer. No muestra si el bug ha desaparecido de verdad, si la nueva rama de un if llega a ejecutarse alguna vez o si la actualización de una dependencia rompe el import en una instalación limpia. Los revisores lo saben, y por eso tantas revisiones terminan con «LGTM, suponiendo que pasen los tests».

Con los parches escritos por IA la brecha se agranda. Un modelo produce código plausible muy rápido, y lo plausible es justo lo que se le escapa a un revisor cansado. La solución barata es ejecutar el cambio antes de que nadie lo apruebe, en un sitio donde no pueda dañar nada.

La comprobación: base, head, tests

La prueba más convincente que puede ofrecer un parche es una reproducción que falla en el código antiguo y pasa en el nuevo. Una sandbox lo convierte en un script de 20 líneas. Es una microVM Firecracker con Python 3.12, Node.js 22, git y curl, que arranca en un segundo aproximadamente:

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 es el fragmento del informe de bug. Si sale con un código distinto de cero en base y con cero en head, el parche arregla lo que dice arreglar. Publica esa línea y el resumen de los tests como comentario en el pull request, y el revisor empieza con hechos.

La suite de tests se ejecuta como tarea en segundo plano porque un solo comando síncrono se detiene a los 55 segundos. El TTL de 30 minutos limita cuánto puede facturar una ejecución atascada.

Agentes de revisión que ejecutan código

La misma idea funciona para un revisor con IA. Conectado mediante el servidor MCP, un agente tiene herramientas de sandbox: crear una sandbox, ejecutar un comando, subir y descargar archivos. En lugar de escribir «esto podría romper la compatibilidad con Python 3.8», descarga la rama, ejecuta el código y cita el traceback, o informa de que todo está bien.

Dale a ese agente un límite de gasto y un token de solo lectura, y decide qué herramientas puede llamar sin preguntar. Las salvaguardas de MCP clasifican cada herramienta por nivel de riesgo.

Qué tarifa

Las sandboxes efímeras se facturan por segundo con un mínimo de 60 segundos. Si un revisor quiere volver al mismo entorno durante un par de días, créalo como persistent: conserva su disco hasta 30 días y se factura por hora iniciada, así que una sandbox standard mantenida para una revisión de dos días cuesta unos $3.17. Bórrala cuando se fusione el pull request.

Límites que conviene conocer

• Dos comandos a la vez por cuenta. De sobra para revisiones, que van una tras otra. Si compruebas decenas de pull requests a la vez, harán cola.
• Sin puertos de entrada. No puedes abrir la aplicación en un navegador. Arráncala dentro y pruébala con curl localhost desde un segundo comando.
• Sin Docker dentro. Los tests que levantan contenedores van en un runner en un VPS.
• La salida a internet está abierta. Es lo que hace funcionar pip install. No metas en la sandbox nada que no le darías al autor del parche.

Para empezar

Las cuentas nuevas reciben $1 de tiempo de sandbox, suficiente para más de cien pasadas de revisión en la tarifa standard. La página de sandboxes tiene las tarifas, la referencia del SDK cada método usado arriba, y el SDK de Python en 5 minutos la configuración.

Relacionado: tests de CI aislados para todo el pipeline, y sandbox para agentes de IA para los agentes que escriben el código en primer lugar.