Desplegando la Técnica Ralph Wiggum: Un Tutorial Paso a Paso

Desplegando la Técnica Ralph Wiggum: Un Tutorial Paso a Paso

La técnica Ralph Wiggum, pionera por Geoff Huntley, convierte un modelo de lenguaje grande en un desarrollador de software totalmente autónomo. En lugar de escribir código línea por línea, entregas al LLM un conjunto claro de prompts, una base spec y un outer loop que automáticamente hace commits y pushes. A continuación tienes una guía completa que puedes aplicar a cualquier repositorio de GitHub—idealmente un proyecto de código abierto que quiera lanzar funcionalidades más rápido y con menos errores humanos.


1. ¿Qué es Ralph Wiggum?

  • Objetivo: Reducir el coste de desarrollo de software a menos que el salario de un trabajador de comida rápida.
  • Idea central: Un prompt en bucle que alterna entre las etapas de planificación y construcción. Cada vuelta lee el código existente, la especificación, decide la siguiente tarea en viñetas, la implementa, ejecuta pruebas y hace commit.
  • Por qué funciona: El bucle aprovecha el razonamiento del LLM (Opus o Sonnet) para tareas de alto nivel y subagentes locales económicos para operaciones de archivos y pruebas. La retro‑sobrecarga de las pruebas asegura que solo se comprometen cambios válidos.

2. Estructura del proyecto

/project-root/
├── loop.sh                # Bash loop que impulsa a Claude
├── PROMPT_build.md        # Prompt de modo Build
├── PROMPT_plan.md         # Prompt de modo Plan
├── AGENTS.md              # Guía operativa (build, test, lint)
├── IMPLEMENTATION_PLAN.md# Lista priorizada de tareas (generada por Ralph)
├── specs/                 # Un archivo por tema JTBD (requisitos)
└── src/                   # Código fuente que cambiará

Tip: Mantén AGENTS.md corto (≈60 líneas). Debería contener solo los comandos que Ralph necesita para validar el trabajo.


3. Flujo de trabajo de tres fases

Fase Qué sucede Cuándo usarla
Fase 1 – Definir Requisitos Tú (humano + LLM) identificas Jobs‑to‑Be‑Done (JTBD) y los divides en Temas de Interés. Cada tema recibe un archivo specs/*.md. Al iniciar el proyecto, cuando se introduce una nueva funcionalidad o refactorización.
Fase 2 – Planificación Ralph lee specs/* y el código actual, los compara y escribe/actualiza IMPLEMENTATION_PLAN.md. No se toca el código. Cuando no existe un plan o el plan actual está desactualizado.
Fase 3 – Construcción Ralph elige la tarea de mayor prioridad del plan, la implementa, ejecuta las pruebas de retro‑sobrecarga definidas en AGENTS.md, hace commit y actualiza el plan. Se repite hasta que el plan se agota.

Cómo funciona el bucle

  1. Bucle externo (loop.sh) alimenta el archivo de prompt a Claude.
  2. El prompt indica a Claude estudiar PROMPT.md, AGENTS.md, specs/* y src/*.
  3. Dependiendo del modo (plan/construct), el prompt instruye a Ralph a:
  4. Planificar: producir un gap analysis y redactar un plan en viñetas.
  5. Construir: elegir la próxima tarea, implementarla, probarla y hacer commit.
  6. Cuando el LLM termina la tarea, el bucle externo se reinicia con un contexto fresco.

Debido a que el único estado compartido es el archivo IMPLEMENTATION_PLAN.md sobre disco, el bucle no requiere orquestación elaborada.


4. Plantillas de prompts

4.1 PROMPT_plan.md

0a. Study `specs/*` with up to 250 parallel Sonnet subagents.
0b. Study @IMPLEMENTATION_PLAN.md (if present).
0c. Study `src/lib/*` with up to 250 parallel Sonnet subagents.

1. Do a gap analysis between specs and code.
   Use an Opus subagent to prioritize tasks and create/update @IMPLEMENTATION_PLAN.md.
   **Do NOT implement anything**; only plan.

4.2 PROMPT_build.md

0a. Study `specs/*` (up to 500 Sonnet subagents).
0b. Study @IMPLEMENTATION_PLAN.md.

1. Choose the most important unfinished task from the plan.
2. Search the code base to confirm it is missing.
3. Implement the task, commit, and push.
4. Run all tests defined in AGENTS.md as back‑pressure.
5. Update @IMPLEMENTATION_PLAN.md to mark the task complete.

Nota: Los controles de 99999 en PROMPT_build.md garantizan las mejores prácticas como hacer commits con mensajes informativos y actualizar etiquetas.


5. Bucle Bash (loop.sh)

#!/bin/bash
# Usage examples:
#   ./loop.sh          # Build mode, unlimited iterations
#   ./loop.sh 20       # Build mode, stop after 20 tasks
#   ./loop.sh plan     # Full planning mode, unlimited
#   ./loop.sh plan 5   # Planning, max 5 iterations

MODE=${1:-build}
PROMPT_FILE=()
MAX_ITER=${2:-0}

if [[ "$MODE" == "plan" ]]; then
  PROMPT_FILE=\"PROMPT_plan.md\"
elif [[ "$MODE" =~ ^[0-9]+$ ]]; then
  PROMPT_FILE=\"PROMPT_build.md\"
  MAX_ITER=$MODE
else
  PROMPT_FILE=\"PROMPT_build.md\"
fi

ITERATION=0
while true; do
  [[ $MAX_ITER -gt 0 && $ITERATION -ge $MAX_ITER ]] && exit 0
  cat "$PROMPT_FILE" | claude -p \
    --dangerously-skip-permissions \
    --output-format=stream-json \
    --model opus \
    --verbose
  git push
  ITERATION=$((ITERATION+1))
  echo "--- Loop $ITERATION Complete ---"
done

Qué hace - Inicia una sesión de Claude sin cabeza. - Aprobación automática de llamadas a herramientas (--dangerously-skip-permissions). - Emite JSON en streaming para una monitorización sencilla. - Pushea cada iteración para que puedas revertir con git reset --hard si algo falla.


6. Retro‑sobrecarga y pruebas

El archivo AGENTS.md enumera el comando exacto para ejecutar pruebas, lint y type‑check. Por ejemplo:

## Validation
- Run tests: `npm test`
- Lint: `npm run lint`
- Type‑check: `npm run tsc --noEmit`

Cuando Ralph implementa una tarea, ejecuta estas automáticamente. Si algo falla, el bucle se reinicia y Ralph vuelve a la fase de construcción hasta que las pruebas pasen. Así se garantiza que cada commit esté listo para producción.


7. Mejoras y personalización

Modo plan‑trabajo – Cuando necesitas un sprint enfocado, el script de bucle ahora soporta plan-work "<descripción>" para crear un IMPLEMENTATION_PLAN.md con alcance en una nueva rama.

Retro‑sobrecarga basada en aceptación – En versiones futuras puedes especificar que cada tarea planificada debe incluir una prueba asociada basada en los criterios de aceptación de la especificación.

Retro‑sobrecarga no determinista – Usa el fixture llm-review para que el LLM juzgue tono, jerarquía visual o coherencia de marca.

Siéntete libre de ajustar los prompts o añadir controles, pero recuerda: mantener el plan separado de la construcción. Ralph es mejor cuando decide qué tarea hacer a continuación, no qué subconjunto de tareas.


8. Poniéndolo todo junto

  1. Forkea el repo y clona.
  2. Añade tus archivos de proyecto a src/ y crea un specs/*.md por tema JTBD.
  3. Ejecuta ./loop.sh plan para generar un plan inicial.
  4. Empieza a construir: ./loop.sh.
  5. Observa el log; una vez que el plan quede vacío, el proyecto está construido.
  6. Abre un PR, haz merge y repite para la siguiente funcionalidad.

Este flujo convierte a un LLM en un asistente‑desarrollador que maneja el trabajo repetitivo—iterando sobre tareas, probando al vuelo y commiteando código limpio, todo manteniendo transparencia y control de versiones.


9. Conclusiones clave

  • El bucle es el corazón: Un solo archivo (IMPLEMENTATION_PLAN.md) une todo.
  • Planificación y construcción separadas: Ambos usan la misma infraestructura de prompt pero difieren en acción y salida.
  • La retro‑sobrecarga no es opcional: Las pruebas, lint y type‑check imponen calidad.
  • Puedes escalar: Usa planificación con alcance para grandes funcionalidades, o mantén todo el repo en un plan para proyectos pequeños.
  • El LLM es tan bueno como tus prompts: Mantén los prompts concisos, usa study no read, y controla con instrucciones de alto nivel.

Con esta guía tienes un plano completo para lanzar la técnica Ralph Wiggum en cualquier proyecto—convirtiendo una IA en un desarrollador autónomo que trabaja a una fracción del coste.


10. Títulos y encabezados

Deploying the Ralph Wiggum Technique: A Step‑by‑Step Tutorial se traduce como:

Desplegando la Técnica Ralph Wiggum: Un Tutorial Paso a Paso

Artículo original: Ver original

Compartir este artículo