Phase 19 - Lesson 16

Capstone 16 — Agente Autónomo GitHub Issue-to-PR

AWS Remote SWE Agents, Cursor Background Agents, OpenAI Codex cloud y Google Jules ofrecen la misma forma de producto en 2026: etiqueta un issue y obtén un PR. Ejecuta un agente en un sandbox en la nube, verifica que las pruebas pasen y publica un PR listo para revisión con su justificación (rationale). Las partes difíciles son reproducir automáticamente el entorno de compilación del repositorio, evitar la filtración de credenciales, aplicar presupuestos por repositorio y garantizar que el agente no pueda realizar force-push. Este capstone construye la versión auto-alojada (self-hosted) y la compara en costo y tasa de aprobación con las alternativas alojadas.

Tipo: Capstone Idiomas: Python (agente), TypeScript (GitHub App), YAML (Actions) Prerrequisitos: Fase 11 (ingeniería de LLM), Fase 13 (herramientas), Fase 14 (agentes), Fase 15 (autónomo), Fase 17 (infraestructura) Fases ejercitadas: P11 · P13 · P14 · P15 · P17 Tiempo: 30 horas

Problema

El agente de codificación asíncrono en la nube es una categoría de producto separada de los agentes de codificación interactivos (capstone 01). La experiencia del usuario (UX) es una etiqueta de GitHub. Etiquetas un issue con @agent fix this, un worker se activa en un sandbox en la nube, clona el repositorio, ejecuta pruebas, edita archivos, verifica y abre un PR con la justificación del agente en el cuerpo. Sin bucle interactivo, sin terminal. AWS Remote SWE Agents, Cursor Background Agents, OpenAI Codex cloud, Google Jules y Factory Droids convergen en esto.

Los desafíos de ingeniería son concretos: reproducción del entorno (el agente tiene que compilar el repositorio desde cero sin una imagen de desarrollo en caché), pruebas inestables (flaky tests, que deben volver a ejecutarse o aislarse), alcance de credenciales (un GitHub App con permisos mínimos y específicos), aplicación de presupuesto por repositorio por día y política de no force-push. El capstone mide la tasa de aprobación (pass rate), el costo y la seguridad frente a las alternativas alojadas.

Concepto

El activador (trigger) es un webhook de GitHub (etiqueta de issue o comentario de PR). Un despachador (dispatcher) encola el trabajo en ECS Fargate o Lambda. El worker extrae el repositorio a un sandbox Daytona o E2B con un Dockerfile genérico inferido a partir del repositorio (idioma, framework). El agente ejecuta un bucle de mini-swe-agent o SWE-agent v2 contra Claude Opus 4.7 o GPT-5.4-Codex. Realiza iteraciones: lee código, propone correcciones, aplica parches, ejecuta pruebas.

La verificación es el paso restrictivo (gate). El CI completo debe pasar en el sandbox antes de que se abra el PR. Se calcula el delta de cobertura; si es negativo más allá de un umbral, el PR se abre pero se etiqueta como needs-review. El agente publica la justificación como la descripción del PR, además de un hilo @agent que el revisor puede mencionar para hacer un seguimiento.

La seguridad se acota a través de dos superficies diferentes de GitHub: la App proporciona un token de instalación de corta duración con permisos de workflows: read y alcances estrechos de contenidos de repositorio/PR; la protección de ramas (no los permisos de la aplicación) impone "no escrituras directas en main" y "no force-push" — la aplicación nunca se añade a la lista de omisión (bypass list). El acceso de solo lectura con alcance de ruta a .github/workflows no es una primitiva real de GitHub App, por lo que la lista de permitidos (allow-list) del agente en las ediciones de archivos tiene que imponer eso en el worker. Los límites presupuestarios por repositorio por día se aplican en el despachador (por ejemplo, máximo 5 PR por repositorio por día,

0 por PR).

Arquitectura

GitHub issue labeled `@agent fix` or PR comment
            |
            v
    GitHub App webhook -> AWS Lambda dispatcher
            |
            v
    ECS Fargate task (or GitHub Actions self-hosted runner)
       - pull repo
       - infer Dockerfile (language, package manager)
       - Daytona / E2B sandbox with target runtime
       - clone -> git worktree -> agent branch
            |
            v
    mini-swe-agent / SWE-agent v2 loop
       Claude Opus 4.7 or GPT-5.4-Codex
       tools: ripgrep, tree-sitter, read/edit, run_tests, git
            |
            v
    verify CI passes in-sandbox + coverage delta check
            |
            v (verified)
    git push + open PR via GitHub App
       PR body = rationale + diff summary + trace URL
       label: needs-review
            |
            v
    operator reviews; can @-mention agent for follow-ups

Pila

Construcción

  1. GitHub App. Token de instalación específico: lectura+escritura de issues, escritura de pull_requests, lectura+escritura de contents, lectura de workflows. La protección de ramas (la única superficie que puede hacerlo) impone "no push directo a main" y "no force-push"; la aplicación no está en la lista de omisión. El worker impone "no escrituras bajo .github/workflows" como una comprobación de lista de permitidos en el diff propuesto, ya que los permisos de GitHub App no tienen alcance de ruta.

  2. Receptor de webhook. La función Lambda acepta webhooks de etiquetas de issues o comentarios de PR. Filtra por la etiqueta @agent fix this. Encola en SQS.

  3. Despachador (Dispatcher). Extrae tareas de SQS. Aplica el presupuesto por repositorio y día. Levanta una tarea de ECS Fargate con la URL del repositorio, el cuerpo del issue y un sandbox Daytona nuevo.

  4. Inferencia de entorno. Detecta el lenguaje (Python, Node, Go, Rust) y el gestor de paquetes (uv, pnpm, go mod, cargo). Genera un Dockerfile sobre la marcha si no existe uno.

  5. Bucle del agente. mini-swe-agent o SWE-agent v2 con Claude Opus 4.7. Herramientas: ripgrep, repo-map de tree-sitter, read_file, edit_file, run_tests, git. Límites estrictos: costo de 0, 30 minutos de tiempo real (wall-clock), 30 turnos del agente.

  6. Verificación. Una vez concluido el bucle, ejecuta la suite de pruebas completa en el sandbox. Calcula el delta de cobertura a través de jacoco / coverage.py. Si el CI está en rojo: se detiene, no abre el PR. Si la cobertura cae más del 2%: abre el PR con la etiqueta needs-review.

  7. Publicación del PR. Sube la rama del agente. Abre el PR a través de la API de GitHub con: título, justificación, resumen de diferencias (diff), URL de traza, costo, turnos.

  8. Higiene de credenciales. El worker se ejecuta con un token de instalación de GitHub App de corta duración. Los registros se depuran de secretos antes de archivarse.

  9. Evaluación (Eval). 30 issues internas sembradas de diversa dificultad. Mide la tasa de aprobación (pass rate), la calidad del PR (tamaño del diff, estilo, cobertura), el costo y la latencia. Compara con Cursor Background Agents y AWS Remote SWE Agents en los mismos issues.

Uso

# on github.com
  - user labels issue #842 with `@agent fix this`
  - PR #1903 appears 14 minutes later
  - body:
    > Fixed NPE in widget.dedupe() caused by null comparator entry.
    > Added regression test widget_test.go::TestDedupeNullComparator.
    > Coverage delta: +0.12%
    > Turns: 7  Cost: 
.80  Trace: langfuse:...
    > Label: needs-review

Entrega

outputs/skill-issue-to-pr.md es el entregable. Un GitHub App + worker asíncrono en la nube que convierte los issues etiquetados en PR listos para revisión con costo limitado y credenciales acotadas.

Peso Criterio Cómo se mide
25 Tasa de aprobación en 30 issues Éxito de extremo a extremo (CI en verde + cobertura OK)
20 Calidad del PR Tamaño del diff, delta de cobertura, conformidad de estilo
20 Costo y latencia por issue resuelto Costo ($) y tiempo real por PR
20 Seguridad Token acotado, presupuesto por repositorio, sin force-push, higiene de credenciales
15 UX del operador Comentarios de justificación, opción de reintento, seguimiento con mención @
100

Ejercicios

  1. Agrega un modo "corrigir prueba inestable": la etiqueta @agent stabilize-flake TestX ejecuta la prueba 50 veces en el sandbox y propone un cambio mínimo que la estabiliza.

  2. Compare el costo con Cursor Background Agents en tres issues compartidos. Reporta qué herramientas ganan en cada caso.

  3. Implementa un panel (dashboard) de presupuesto: costo por repositorio y día, costo por usuario. Alerta en caso de anomalía.

  4. Crea un modo de "ejecución simulada" (dry-run) que abre un borrador de PR (draft PR) sin ejecutar CI, para que los revisores puedan examinar el plan de forma económica.

  5. Agrega una política de retención: las ramas de PR con más de 7 días sin fusionar se eliminan automáticamente.

Términos Clave

Término Lo que la gente dice Lo que realmente significa
GitHub App "Identidad de bot acotada" Aplicación con permisos específicos + token de instalación de corta duración
Agente asíncrono en la nube "Agente de segundo plano" Worker no interactivo que se ejecuta en un sandbox en la nube, no en una terminal
Inferencia de entorno "Síntesis de Dockerfile" Detecta el lenguaje + gestor de paquetes, genera un Dockerfile si no está presente
Verificación "CI en el sandbox" Ejecuta la suite de pruebas completa dentro del worker antes de abrir un PR
Delta de cobertura "Preservación de cobertura" Cambio en el % de cobertura de pruebas de la rama base a la rama del agente
Presupuesto por repositorio "Límite diario" Límite de dólares y conteo de PR aplicado en el despachador (dispatcher)
Justificación "Explicación en el cuerpo del PR" Resumen del agente sobre lo que cambió y por qué; requerido en el cuerpo del PR

Lecturas Adicionales