Cómo construir un agente de ingeniería sénior: orquestación de subagentes, loop engineering y PRs automáticos

TL;DR

• Un agente de ingeniería sénior no es un chatbot más inteligente. Es un orquestador: planifica el trabajo, escribe prompts estructurados para subagentes especialistas, los ejecuta en espacios de trabajo aislados, verifica el resultado y solo entonces abre un pull request.
• En 2026, esta práctica se conoce como loop engineering: deja de darle prompts a los agentes turno por turno y, en cambio, diseña el loop que se los proporciona. Boris Cherny (líder de Claude Code) lo dijo sin rodeos: «Mi trabajo es escribir loops». Addy Osmani le dio nombre a la práctica y describió su anatomía.
• La parte difícil no es generar código. Es generar confianza. Los PRs automáticos de alta confianza necesitan una separación entre quien implementa y quien verifica, una condición de salida verificable (CI en verde, pruebas que pasan, diff limpio) y un estado persistente que sobreviva entre ejecuciones.
• Adopta el instinto de ponytail: el mejor ingeniero sénior escribe la menor cantidad de código que resuelve por completo el problema. Es más fácil revisar y confiar en un orquestador que entrega diffs más pequeños y acotados.
• Empieza con tareas acotadas que tengan un resultado binario de aprobado o fallido (actualizaciones de dependencias, codemods, correcciones de pruebas intermitentes). Gana autonomía de forma gradual. No empieces dejando que un agente diseñe tu arquitectura y haga merge a las 3 a. m.
• Las mayores brechas hoy son la deuda de comprensión, el reward hacking contra el verificador, la cobertura de contexto y conocimiento y el sesgo hacia la acción (los agentes cambian código incluso cuando no hace falta).

Qué aprenderás aquí

• Qué es realmente un «agente de ingeniería sénior» y por qué el objetivo de diseño es la orquestación, no la inteligencia por sí sola.
• Cómo el loop engineering y los flujos de trabajo con agentes proactivos transforman el papel humano: de quien escribe prompts a quien diseña loops.
• Una arquitectura de referencia concreta: planificador, generador de prompts, subagentes ejecutores, verificador y control de apertura de PRs.
• Cómo generar prompts bien estructurados para subagentes a modo de especificaciones, con una plantilla reutilizable.
• Una escalera de confianza que responde a la pregunta: ¿cuánto conocimiento necesitas antes de que un PR automático sea confiable?
• Una lista honesta de brechas y supuestos, además de dónde encajan ponytail, Ralph y los frameworks multiagente.

Este artículo es para ingenieros (y PMs curiosos) que ya usan agentes de código a diario y quieren pasar de «le doy un prompt a un agente» a «ejecuto un sistema que entrega cambios revisables».

El instinto de ingeniería sénior: entregar menos, con certeza

Antes de hablar de arquitectura, hablemos de mentalidad. El proyecto viral ponytail incorpora en un agente la regla del desarrollador sénior más perezoso: antes de escribir código, detente en el primer peldaño que resuelva el problema.

1. Does this need to exist?  -> no: skip it (YAGNI)
2. Stdlib does it?           -> use it
3. Native platform feature?  -> use it
4. Installed dependency?     -> use it
5. One line?                 -> one line
6. Only then: the minimum that works

El objetivo no es ahorrar tokens a toda costa. La idea es que un ingeniero sénior nunca sacrifica la validación, el manejo de errores, la seguridad ni la accesibilidad, pero tampoco construye una clase de caché de 120 líneas que la tarea no pidió. Esto importa enormemente para la automatización: un diff pequeño y necesario se puede revisar; uno extenso y especulativo, no. Si quieres PRs automáticos en los que puedas confiar, el orquestador debe heredar esta mesura, no solo la capacidad de generar código.

Esta también es la forma honesta de replantear el concepto de «agente de ingeniería sénior». La experiencia sénior consiste, sobre todo, en saber qué no hacer: qué trabajo omitir, qué riesgo escalar y cuándo «sin cambios» es la respuesta correcta.

De los prompts al loop engineering

En la primera semana de junio de 2026, la conversación sobre programación con IA se reorganizó alrededor de una idea. Peter Steinberger (creador del proyecto de agentes OpenClaw, ahora en OpenAI) publicó que la habilidad ya no consiste en darles prompts a los agentes de código, sino en diseñar los loops que se los proporcionan. Boris Cherny, quien lidera Claude Code en Anthropic, lo describió así en el podcast Acquired: «Ya no le doy prompts a Claude. Tengo loops ejecutándose que le dan prompts a Claude y deciden qué hacer. Mi trabajo es escribir loops». El ensayo de Addy Osmani, ampliamente compartido, le dio a la práctica un nombre, loop engineering, y una anatomía.

El desglose de Osmani se corresponde casi exactamente tanto con la app de Codex como con Claude Code (la convergencia es lo interesante). Un loop tiene seis componentes:

Aquí resulta útil un modelo mental de tres niveles:

• Harness engineering — el entorno de ejecución alrededor de un agente (herramientas, memoria, permisos).
• Loop engineering — el harness que se ejecuta según una programación, crea agentes auxiliares y se alimenta de información almacenada en disco.
• Orquestación — flotas de agentes que trabajan con worktrees, PRs y CI, con fallos dirigidos de vuelta a la sesión correcta.

Un agente de ingeniería sénior vive en la frontera entre el loop y la orquestación.

Arquitectura de referencia

Esta es una estructura práctica en la que convergen varios sistemas abiertos (la separación entre quien implementa y quien verifica refleja cómo trabajan los equipos humanos). Piensa en el agente de ingeniería sénior como un orquestador ligero que delega la mayor parte del trabajo.

                        ┌─────────────────────────────┐
   trigger (issue,      │   Senior-Engineer Agent      │
   schedule, label) ──> │       (orchestrator)         │
                        └──────────────┬──────────────┘
                                       │ 1. read goal + durable state
                                       v
                              ┌────────────────┐
                              │    PLANNER      │  decompose into atomic,
                              │  (subagent)     │  dependency-aware tasks
                              └───────┬─────────┘
                                      │ 2. emit task graph
                                      v
                          ┌──────────────────────┐
                          │   PROMPT GENERATOR    │  turn each task into a
                          │   (structured spec)   │  self-contained subagent brief
                          └──────────┬────────────┘
                                     │ 3. dispatch (parallel, isolated worktrees)
              ┌──────────────────────┼──────────────────────┐
              v                      v                      v
        ┌───────────┐         ┌───────────┐          ┌───────────┐
        │ WORKER #1 │         │ WORKER #2 │   ...    │ WORKER #N │  implement
        │ (maker)   │         │ (maker)   │          │ (maker)   │
        └─────┬─────┘         └─────┬─────┘          └─────┬─────┘
              └──────────────────────┼──────────────────────┘
                                     v
                            ┌─────────────────┐
                            │    VERIFIER     │  4. build, tests, lint,
                            │    (checker)    │     security, contract checks
                            └───────┬─────────┘
                            pass ┌──┴──┐ fail
                                 v     v
                          ┌────────┐  └─> route failure + diff back to PLANNER
                          │  PR    │      (bounded retries, then escalate)
                          │ GATE   │  5. open PR, update ticket, write state
                          └────────┘

Dos reglas de diseño determinan si esto funciona o no:

1. Quien implementa nunca se aprueba a sí mismo. Un verificador independiente (con un prompt diferente e idealmente herramientas de solo lectura para la revisión) decide si el resultado pasa o falla. La autoevaluación es la causa más común de fallos en los PRs automáticos.
2. El estado vive en disco, no en el contexto. Las tareas, el estado, los intentos y las decisiones van a un archivo o tablero (el patrón Ralph trata el sistema de archivos y git como memoria principal). Cada iteración puede comenzar desde cero y aun así saber qué se ha hecho.

Cómo generar prompts bien estructurados para subagentes

La tarea más subestimada del orquestador es la generación de prompts. Un subagente falla no porque sea incapaz, sino porque recibió instrucciones vagas. Trata cada prompt para un subagente como una especificación, no como una frase.

Un conjunto de instrucciones estructuradas y confiables tiene seis campos:

ROLE        narrow job description (one specialty, not "senior engineer")
CONTEXT     only what this task needs: files, conventions, constraints
GOAL        the single outcome, stated as a verifiable condition
NON-GOALS   what to skip (YAGNI / ponytail restraint)
TOOLS       allowed tools + permission boundaries
DONE-WHEN   the exact pass/fail signal (tests, build, diff shape)

En concreto, el orquestador podría generar esto para una tarea del grafo:

ROLE: Backend test-fix specialist. You only fix the failing test and its cause.

CONTEXT:
- Repo uses Vitest. Run tests with `npm test`.
- Failing test: `src/auth/session.test.ts > refreshes expired token`.
- Convention: no new dependencies without escalation.

GOAL: Make the failing test pass without weakening assertions.

NON-GOALS:
- Do not refactor unrelated files.
- Do not add a caching layer or new abstraction.
- If the test is wrong (not the code), stop and report evidence.

TOOLS: Read, Edit, Run(`npm test`, `npm run lint`). No network. No deps.

DONE-WHEN:
- `npm test` is green AND `npm run lint` passes.
- `git diff` touches only `src/auth/**` and the test file.

Observa que la especificación incorpora mesura (NON-GOALS), una condición de salida binaria (DONE-WHEN) y una vía de inacción («si la prueba está equivocada, detente e informa»). Esa última línea no es una cortesía opcional. Un artículo de mayo de 2026 (Coding Agents Don’t Know When to Act) encontró que los agentes propusieron cambios indeseables en muchas tareas que no requerían cambios. El sesgo hacia la acción es un modo de fallo real; las instrucciones deben permitir «sin cambios» como resultado válido.

Un pequeño generador que convierte un nodo del grafo de tareas en esas instrucciones se ve así:

type Task = {
  role: string;
  goal: string;
  context: string[];
  nonGoals: string[];
  tools: string[];
  doneWhen: string[];
};

function renderBrief(t: Task): string {
  const list = (xs: string[]) => xs.map((x) => `- ${x}`).join("\n");
  return [
    `ROLE: ${t.role}`,
    ``,
    `CONTEXT:\n${list(t.context)}`,
    ``,
    `GOAL: ${t.goal}`,
    ``,
    `NON-GOALS:\n${list(t.nonGoals)}`,
    ``,
    `TOOLS: ${t.tools.join(", ")}`,
    ``,
    `DONE-WHEN:\n${list(t.doneWhen)}`,
  ].join("\n");
}

La calidad del orquestador depende principalmente de la calidad de estas instrucciones. Si solo puedes mejorar una cosa, mejora el generador de prompts, no el modelo que ejecuta el trabajo.

¿Cuánto conocimiento necesitas para obtener PRs automáticos de alta confianza?

Esta es la pregunta de la que depende todo el sistema. Un PR automático solo es tan confiable como la señal verificable que lo respalda. La confianza no es una corazonada; es el resultado de la cobertura en varios ejes.

Piensa en ello como una escalera de confianza. Cada peldaño añade conocimiento que el sistema debe tener antes de poder abrir un PR que aceptarías sin leer.

        higher autonomy (merge unread)
                  ▲
   L5 │ Org policy + ownership + change-budget guardrails
   L4 │ Maker/checker split with an INDEPENDENT verifier
   L3 │ Strong, fast verifiable signal (tests + CI + types + lint)
   L2 │ Codebase conventions captured (skills / AGENTS.md)
   L1 │ Task is narrow with a binary pass/fail outcome
   L0 │ Goal is unambiguous and reversible
                  │
        lower autonomy (human reviews everything)

En la práctica:

• L0–L1 (empieza aquí). Elige tareas reversibles con una señal binaria: actualizaciones de dependencias, codemods, correcciones de lint y reparación de pruebas intermitentes. El consejo de Steinberger es empezar justamente aquí, ejecutar el loop en producción durante unas semanas y luego ampliar su alcance.
• L2. El agente debe conocer tus convenciones sin tener que redescubrirlas. Para eso sirven AGENTS.md/CLAUDE.md y las skills. La ausencia de convenciones es la causa #1 de diffs «técnicamente correctos, pero incompatibles con la cultura del equipo».
• L3. Los PRs automáticos dependen de la calidad de la suite de pruebas y CI que deben superar. Si tu verificador es débil, la autonomía es peligrosa, no impresionante. Lo que realmente importa aquí es la cobertura de la superficie modificada.
• L4. Un verificador independiente evita que quien implementa evalúe su propio trabajo. Sin él, aparece el reward hacking: el agente consigue que la señal esté en verde eliminando una prueba, flexibilizando una aserción o capturando e ignorando errores.
• L5. Para hacer merges sin supervisión, necesitas reglas de propiedad, límites del alcance de impacto (presupuestos de cambio, rutas protegidas) y políticas. Esta es la brecha entre «un loop en mi terminal» y «un loop que la empresa ejecuta a las 3 a. m.».

Entonces, ¿cuánto conocimiento hace falta? El suficiente para que el verificador pueda demostrar que se cumplió el objetivo sin que una persona tenga que comprobarlo todo de nuevo. En concreto, para un PR automático de una funcionalidad necesitas: la especificación de la tarea, las convenciones relevantes, una prueba que codifique los criterios de aceptación, una revisión independiente aprobada y un alcance de impacto acotado. Con menos que eso, el PR es un borrador para una persona, lo cual sigue siendo útil, pero no es automatización «de alta confianza».

Un loop proactivo mínimo

Los agentes proactivos no esperan un prompt; reciben un objetivo, descubren trabajo y presentan sus hallazgos. Esta es la versión mínima y realista del loop externo, expresada como pseudocódigo que el orquestador ejecuta para cada tarea.

def run_task(task, max_attempts=3):
    worktree = create_worktree(task.id)          # isolation: no file collisions
    state.mark(task, "in_progress")

    for attempt in range(1, max_attempts + 1):
        brief = render_brief(task)               # structured spec, not a sentence
        diff = maker_agent.run(brief, cwd=worktree)

        report = verifier_agent.run(             # independent checker
            diff=diff, suite=["build", "test", "lint", "security"]
        )
        if report.passed and within_change_budget(diff):
            pr = open_pr(worktree, task, report)  # connector does the side effect
            state.mark(task, "pr_open", pr.url)
            return pr

        task = add_feedback(task, report)        # feed failure back in
        state.record_attempt(task, attempt, report)

    escalate_to_human(task, state.history(task)) # bounded retries, then stop

Tres propiedades hacen que esto sea seguro en lugar de imprudente:

• Aislamiento — cada tarea se ejecuta en su propio worktree, de modo que quienes implementan en paralelo nunca corrompen el trabajo de los demás.
• Reintentos limitados — «seguir intentando» sin límite desperdicia dinero y oculta supuestos incorrectos. Limita los intentos y luego escala el problema.
• Estado persistente — cada intento se registra fuera del modelo para que el loop pueda reanudarse y auditarse.

Puedes integrar esto en una automatización (una programación o un evento como una nueva etiqueta agent-ready) y una bandeja de clasificación, donde las ejecuciones que encuentran algo se presentan para revisión y las que no encuentran nada se archivan automáticamente. Esa bandeja es lo que convierte un script de uso único en un loop que realmente mantienes.

Brechas y supuestos (lee esto antes de automatizar)

Una sección de honestidad. La arquitectura anterior es sólida, pero se apoya en supuestos que no siempre se cumplen en repos reales.

• Supuesto: el verificador es confiable. Si las pruebas son escasas, la marca verde es puro teatro. El reward hacking (eliminar o debilitar pruebas para que pasen) es un modo de fallo documentado. Mitigación: revisa el diff de las pruebas por separado y prohíbe eliminar pruebas sin escalarlo.
• Supuesto: las convenciones están documentadas. Si tus normas solo existen en la cabeza de los ingenieros sénior, el agente no puede seguirlas. Mitigación: invierte en AGENTS.md/skills antes de otorgar autonomía, no después.
• Deuda de comprensión. Incluso cuando el código es correcto, nadie en el equipo lo entiende. Los cambios escritos por agentes que se incorporan sin leer acumulan una deuda que crece con el tiempo. Mitigación: mantén los diffs pequeños (el instinto de ponytail) y exige revisión humana por encima de L4.
• Sesgo hacia la acción. Los agentes actúan de más. La vía «sin cambios es un resultado válido» debe estar explícita en cada conjunto de instrucciones.
• El costo y la latencia no son gratis. Los benchmarks de loop engineering varían según el modelo: los modelos de razonamiento conciso pueden gastar más en pensar de lo que ahorran, y el costo por sesión (el conjunto de reglas se vuelve a inyectar en cada turno) puede resultar mayor o menor. Mide tu propio loop.
• El paralelismo multiplica la carga de revisión. N subagentes paralelos producen N diffs. Si no puedes revisarlos, no ganaste capacidad: desplazaste el cuello de botella.
• Brecha empresarial. Un loop en tu laptop no es un entorno de ejecución gobernado. Los merges sin supervisión necesitan responsables, registros de auditoría, políticas y límites del alcance de impacto que faltan en la mayoría de las configuraciones personales.

El supuesto central: tú sigues siendo el ingeniero. El loop engineering eleva el punto desde el que ejerces influencia; no te reemplaza. Construye el loop como alguien que piensa seguir siendo responsable de lo que entrega.

El estado actual del ecosistema

Un panorama rápido, sustentado en fuentes, para ubicar estas ideas:

• Loop engineering (Osmani, Cherny, Steinberger) es el marco conceptual: diseña el loop, no el turno.
• Ralph / Ralph TUI (basado en el patrón de Geoffrey Huntley) implementa loops continuos que tratan git y el sistema de archivos como memoria y procesan un backlog de tareas atómicas hasta completarlo.
• Frameworks multiagente para ingeniería de software (por ejemplo, auto-swe-agent con máquinas de estados de LangGraph y la visión de investigación de ALMAS que alinea agentes con roles ágiles) formalizan la división del trabajo entre planificador → programador → ejecutor → verificador.
• ponytail es el contrapeso cultural: el mejor ingeniero sénior entrega la menor cantidad de código que resuelve por completo el problema, que es precisamente la propiedad que hace revisables los PRs automáticos.

No son religiones opuestas. Un buen agente de ingeniería sénior toma el loop del loop engineering, la separación entre quien implementa y quien verifica de los frameworks multiagente, la disciplina de usar el sistema de archivos como memoria de Ralph y la mesura de ponytail.

Brechas de este artículo

Siguiendo el espíritu de la escalera de confianza, esto es lo que el artículo todavía no cubre:

• Sin benchmark comparativo directo de herramientas. La app de Codex, Claude Code, Cursor y OpenClaw evolucionan cada semana; las cifras específicas quedarían obsoletas rápidamente.
• Sin modelo de seguridad para producción. Los permisos de herramientas, el manejo de secretos y el consentimiento de MCP para un orquestador sin supervisión merecen su propio artículo.
• Sin caso de estudio real. La arquitectura es una síntesis de fuentes primarias y proyectos abiertos, no el resultado de un único despliegue en producción medido.
• Evaluación poco desarrollada. «¿Cómo se evalúa el propio orquestador a lo largo del tiempo?» (regresión de la tasa de merge, la tasa de reversión y el tiempo de revisión) apenas se esboza.
• El modelo de costos es cualitativo. Se mencionan presupuestos de tokens/latencia/$ por tarea, pero no se modelan.

Secciones recomendadas para una versión futura:

• un AGENTS.md y un conjunto de skills concretos, adaptados a un orquestador
• una lista de verificación para reforzar el verificador (reglas contra el reward hacking)
• un ejemplo de política de presupuesto de cambios y rutas protegidas
• un dashboard de tasa de reversión y deuda de comprensión para PMs
• un ejemplo completo de un loop de actualización de dependencias, de principio a fin, con CI real

Fuentes

• Addy Osmani: Loop Engineering — el ensayo de referencia que da nombre a la práctica y a sus seis primitivas (automatizaciones, worktrees, skills, conectores, subagentes y estado persistente).
• Loop Engineering de nivel empresarial (TrueFoundry) — la brecha entre un loop en una laptop y un entorno de ejecución gobernado; la anatomía de seis componentes y las citas de Cherny y Steinberger.
• Loop Engineering: por qué los mejores ingenieros dejaron de dar prompts a su IA (Mindber) — por dónde empezar (actualizaciones de dependencias, codemods y pruebas intermitentes) y cómo ganar confianza de forma gradual.
• Loop Engineering: diseña sistemas de agentes de código en lugar de dar prompts en cada turno (Mervin Praison) — el modelo de tres niveles: harness, loop y orquestación.
• ¿Qué es el loop engineering? (Kilo) — definir el objetivo, actuar, observar y revisar; reglas de parada explícitas y reintentos limitados.
• DietrichGebert/ponytail — el conjunto de reglas del «desarrollador sénior más perezoso», la escalera YAGNI y el argumento de que los diffs pequeños facilitan el mantenimiento.
• Cómo los agentes de IA autónomos están transformando los flujos de trabajo de desarrollo en 2026 (DEV) — patrones en los que un orquestador dirige el trabajo a subagentes y recomendaciones para ajustar la complejidad a la necesidad.
• YashKasare21/auto-swe-agent — un sistema multiagente de ingeniería de software (planificador/programador/ejecutor/verificador) con estado de LangGraph y ejecución aislada.
• ALMAS: framework multiagente autónomo de ingeniería de software basado en LLMs — alineación de agentes con roles ágiles a lo largo del SDLC.
• Ralph TUI — orquestador de loops de agentes de IA — loops continuos para procesar backlogs, tareas atómicas, el sistema de archivos y git como memoria, y trazabilidad de subagentes.
• Los agentes de código no saben cuándo actuar (arXiv) — sesgo hacia la acción y cambios indeseables en tareas que no requieren cambios.