🛰️ Setup AFK completo

El corazón de la configuración de Pocock es simple y nada exótico: usa el Claude Code en ejecución Opus 4.8 en medium effort. Fíjate en el detalle: él no usa el modelo más «esforzado» disponible de forma predeterminada (y, en sus palabras, «NO Fable"). El nivel medium es el punto de equilibrio: lo bastante bueno para planificar e implementar, sin gastar demasiados tokens. Recuerda la Trilha 1: el resultado es 50/50 entre el modelo y el harness, así que no vale la pena gastar todo el presupuesto solo aumentando el «effort» del motor.

También hay una disciplina de paciencia con el modelo nuevo: Matt espera alrededor de 1 mes antes de adoptar un modelo recién lanzado (hizo exactamente eso con el Opus 4.5). ¿Por qué? Porque cambiar de motor cada semana es el error de vibe coder de la Trilha 1: pasas tiempo reoptimizando en vez de construir. El Claude Code local sirve para dos cosas en su flujo: (1) planificar la tarea contigo presente (human-in-the-loop) y (2) hacer parte de la implementación ahí mismo, cuando se trata de algo complejo o que aún no está bien definido. La mayor parte del trabajo repetitivo va para AFK, que veremos a continuación. Error común: creer que "AFK" significa dejar todo sin volver a abrir Claude Code; en realidad, el trabajo local de planificación es lo que hace que AFK funcione.

A la mayor parte del trabajo de Matt es AFK: activa el agente y se va. Pero hay una regla de oro que no negocia: AFK solo dentro de un sandbox. Un sandbox es un entorno cerrado, separado de tu computadora real. Sin él, un agente que se ejecuta por su cuenta puede causar daños reales; en palabras del propio Pocock, puede "eliminar tu directorio home" (borrar tu carpeta de usuario) o "exfiltrar env vars" (filtrar tus variables de entorno — donde se guardan contraseñas, tokens de API, claves). No es paranoia: es el agente actuando sin que nadie lo supervise.

La lógica es directa: quien está en el loop (mientras tú supervisas) puedes aprobar cada paso peligroso; quien está AFK no hay nadie que apruebe nada — así que el entorno debe ser seguro por construcción. El sandbox permite eso: el agente lee el código, lo edita, ejecuta pruebas y hace commits, pero todo dentro de la caja. Si algo sale mal, descartas la caja y nada de tu sistema se ve afectado. Por eso la frase de Matt es «AFK is just incredible — takes a bit of setup, but then it goes": el "bit of setup" es precisamente configurar el sandbox una vez. Después, escala por sí solo.

La herramienta concreta que usa Matt para este flujo es Sand Castle. Hace dos cosas: (1) ejecuta los agentes dentro de sandboxes — y aquí eliges el «motor» del sandbox: Docker o Podman (en tu máquina) o Vercel sandboxes (en la nube); y (2) organiza el trabajo como cola de issues — cada tarea es una issue que un sandbox detecta y resuelve. Como vimos en la Trilha 4, Matt piensa el desarrollo como una fila de tareas, no un loop: "all development is just a queue of tasks".

En la práctica, la configuración mínima de Sand Castle es: instalar la herramienta, tener Docker (o Podman) en ejecución, apuntar a tu repositorio y dar la configuración del agente: qué herramienta de programación (Claude Code), qué modelo (Opus 4.8) y qué nivel de esfuerzo (medium). A partir de ahí, le das una issue («implementa X») y Sand Castle crea un sandbox nuevo, hace que el agente trabaje allí y produce commits. ¿Por qué es tan poderoso? Porque el "un poco de configuración" se paga una sola vez — después, abrir una nueva tarea cuesta tan poco como crear un issue. Error común: intentar ejecutar Sand Castle sin tener Docker/Podman activo: sin el motor de contenedores, no hay sandbox donde colocar al agente.

Aquí está el truco de la configuración AFK: como cada agente se ejecuta en el tu propio sandbox aislado, puedes ejecutar muchos al mismo tiempo sin que uno se interponga en el otro. Matt lo resume: ejecutar agentes mediante "Sand Castle on GitHub Actions — unreasonably effective, parallelize as much as you want, not worried about local resources" (irracionalmente eficaz, paraleliza todo lo que quieras, sin preocuparte por los recursos locales). Es el "two, three, four, five of me" de la Ruta 4 hecha realidad: varios "tú" trabajando en paralelo.

La pieza que desbloquea el paralelismo en la nube es el GitHub Actions. En vez de que cada agente consuma CPU y RAM de tu notebook, se ejecutan en los servidores de GitHub, así que la cantidad no depende de tu máquina. Pero atención a la orden de las dos reglas: paralelizar solo es seguro porque cada agente está aislado. Sin sandbox, ejecutar 5 agentes sueltos al mismo tiempo multiplica por 5 las posibilidades de causar daños. Error común: "paralelizar para ir más rápido" desactivando el aislamiento: cambias velocidad por el riesgo de borrar el repositorio. La receta correcta es: aísla primero, paraleliza después.

El agente trabajó de forma aislada y generó el resultado dentro del sandbox. Ahora falta la última pieza: traer ese resultado de vuelta a tu repositorio. En Git, ese resultado llega como commits en una branch propia, envueltos en un PR (pull request). El flujo de Matt encaja directamente en la Trilha 4: el agente AFK produce un PR como salida, y el PR es exactamente el punto donde tú entra a revisar antes de fusionar. No recibes el código en bruto del sandbox: recibes un PR limpio, lees el diff, lo apruebas (o pides ajustes).

Este es el punto de control de revisión desplazado hacia la derecha de la Trilha 4: el humano no interviene en cada paso; entra al final, cuando ya hay un PR listo para evaluar. Con los buenos PR, haces el merge; con los dudosos, pides otra ronda o te encargas tú mismo. Error común: dejar los commits «atrapados» en el sandbox y nunca traerlos — o, en el extremo opuesto, configurar auto-merge sin que nadie revise. El punto de equilibrio de Matt es: el agente crea el PR, el humano lo aprueba. A continuación, el resumen del flujo de salida para que lo copies.

# O agente AFK rodou no sandbox e abriu um PR. Traga pra revisar:

# 1) ver os PRs que os agentes AFK abriram
gh pr list --label "agent:implement"

# 2) baixar a branch do PR pra inspecionar localmente
gh pr checkout 795          # nº do PR aberto pelo agente

# 3) ler o que mudou ANTES de aceitar (você é o checkpoint)
git diff main...HEAD

# 4a) aprovou? faça o merge
gh pr merge 795 --squash --delete-branch

# 4b) precisa de ajuste? volte pro Claude Code local e itere
#     (ou peça outra rodada AFK na mesma issue)

Al cerrar el módulo: aquí está el configuración mínima reunido en un solo lugar, listo para copiar. Son tres bloques — (1) el configuración de Claude Code fijando Opus 4.8 en medium effort; (2) el comando para ejecutar al agente AFK en sandbox (Sand Castle apuntado a tu repo); y (3) los pasos para recuperar los commits. Es el esqueleto exacto del flujo de Matt, reducido a lo esencial. Empieza por aquí hoy, ejecuta una tarea pequeña AFK, y ve aumentando la cola.

# ── 1) CONFIG DO CLAUDE CODE: Opus 4.8 em medium effort ──
# ~/.claude/settings.json (modelo + esforço fixos, como o Matt usa)
{
  "model": "claude-opus-4-8",
  "effort": "medium"
}
# (ou na sessão)  →  /model claude-opus-4-8   |   /effort medium
# uso local: planejar + parte da implementação, você junto.

# ── 2) RODAR O AGENTE AFK EM SANDBOX (Sand Castle) ──
# pré-requisito: Docker (ou Podman) ativo  →  docker info
# instalar e apontar pro seu repo:
npx sandcastle@latest init        # cria a config no projeto
# disparar uma tarefa AFK isolada (1 sandbox por issue):
sandcastle run \
  --issue 795 \                   # a tarefa da fila
  --sandbox docker \              # docker | podman | vercel
  --agent claude-code \           # ferramenta de codar
  --model claude-opus-4-8 \
  --effort medium
# paralelizar: dispare várias issues; cada uma vira um sandbox isolado.

# ── 3) PUXAR OS COMMITS DE VOLTA (você é o checkpoint) ──
gh pr list --label "agent:implement"   # PRs que os agentes abriram
gh pr checkout 795                      # baixar pra inspecionar
git diff main...HEAD                    # LER o diff antes de aceitar
gh pr merge 795 --squash --delete-branch   # aprovou? merge.