Phase 14 - Lesson 41

El Banco de Trabajo en un Repositorio Real

Once lecciones de superficies no sirven de nada si no sobreviven al contacto con una base de código real. Esta lección ejecuta la misma tarea dos veces en una pequeña aplicación de ejemplo: solo con prompt frente a guiada por el banco de trabajo. Los números hablan por sí solos.

Tipo: Build Lenguajes: Python (stdlib) Prerrequisitos: Fases 14 · 32 a 14 · 40 Tiempo: ~60 minutos

Objetivos de Aprendizaje

  • Reunir las siete superficies del banco de trabajo en una pequeña aplicación.
  • Ejecutar la misma tarea dos veces (solo con prompt y guiada por el banco de trabajo) y medir cinco resultados.
  • Leer el informe antes/después y decidir qué superficies dieron el mayor apalancamiento.
  • Defender el banco de trabajo frente a la objeción de "pero mi modelo es lo suficientemente bueno".

El Problema

Una demostración en una tarea de juguete no convence a nadie. El caso a favor del banco de trabajo se consolida cuando una tarea que parece real en un repositorio que parece real llega a producción con menos fallas, menos reversiones y un paquete que la siguiente sesión puede utilizar.

Esta lección incluye ese repositorio que parece real y ejecuta la misma tarea a través de ambos pipelines. El resultado es un informe antes/después que puedes entregar a un escéptico.

El Concepto

flowchart TD
  Task[Tarea: validar /signup y agregar pruebas] --> A[Ejecución solo con prompt]
  Task --> B[Ejecución guiada por el banco de trabajo]
  A --> M[Medir: 5 resultados]
  B --> M
  M --> Report[before-after-report.md]

La aplicación de ejemplo

Un manejador minimalista al estilo de FastAPI en sample_app/:

  • app.py con /signup (sin validación aún).
  • test_app.py con una prueba de camino feliz (happy-path).
  • README.md y scripts/release.sh como cebo para la zona prohibida.

La tarea

Agrega validación de entrada a /signup: rechaza contraseñas de menos de 8 caracteres, devuelve 422 con un sobre de error tipado. Agrega una prueba que demuestre el nuevo comportamiento.

Los dos pipelines

Solo con prompt:

  1. Leer el README.
  2. Leer app.py.
  3. Editar archivos.
  4. Declarar terminado.

Guiada por el banco de trabajo:

  1. Ejecutar script de inicio (Lección 35).
  2. Leer contrato de alcance (Lección 36).
  3. Leer estado (Lección 34).
  4. Editar solo los archivos permitidos.
  5. Ejecutar comando de aceptación a través del ejecutor de retroalimentación (Lección 37).
  6. Ejecutar barrera de verificación (Lección 38).
  7. Ejecutar revisor (Lección 39).
  8. Generar handoff (Lección 40).

Los dos resultados medidos

Resultado Por qué es importante
tests_actually_run La mayoría de las afirmaciones de "pruebas aprobadas" no se pueden verificar
acceptance_met La prueba que demuestra el objetivo debe ser la prueba que se ejecutó
files_outside_scope El desvío del alcance (scope creep) es la falla silenciosa dominante
handoff_quality La siguiente sesión paga por esto o se beneficia de ello
reviewer_total Juicio cualitativo por encima de la barrera

Build It

code/main.py orquesta los dos pipelines contra el mismo fixture de aplicación de ejemplo. Ambos pipelines están automatizados mediante scripts (sin LLM en el bucle) para que la medición sea reproducible. El script escribe la comparación en before-after-report.md y comparison.json.

Ejecútalo:

python3 code/main.py

Salida: una tabla en consola con los resultados por pipeline, el informe en markdown guardado junto al script y el JSON para quien quiera graficarlo.

Patrones de producción en el mundo real

La pregunta del escéptico es "¿cuánto ayuda realmente el banco de trabajo?" Los números de 2026 dicen mucho más que la explicación.

De Top-30 a Top-5 en Terminal Bench con el mismo modelo. Anatomy of an Agent Harness de LangChain (abril de 2026): un agente de codificación saltó desde fuera del top 30 al puesto cinco en Terminal Bench 2.0 cambiando únicamente el harness. Mismo modelo. Diferentes superficies. Diferencia de veinticinco puestos.

Vercel: de 80% a 100% eliminando herramientas. Vercel informó que eliminar el 80% de las herramientas de su agente elevó la tasa de éxito del 80% al 100%. Menor superficie de herramientas, alcance más definido, menos formas de fallar. El espacio negativo gana.

Harvey: el doble de precisión solo mediante harness. Los agentes legales duplicaron con creces su precisión gracias a la optimización del harness, sin ningún cambio de modelo.

El 88% de los proyectos de agentes de IA empresariales no logran llegar a producción. El artículo Harness Engineering for Language Agents de preprints.org (marzo de 2026) atribuye los fallos al tiempo de ejecución (runtime), no al razonamiento: estado obsoleto, reintentos frágiles, contexto excesivo, mala recuperación de errores intermedios.

Colapso por contexto largo. El éxito inicial de 40-50% de WebAgent cae a menos del 10% en condiciones de contexto largo, debido principalmente a bucles infinitos y pérdida de objetivos. El Ralph Loop y el paquete de handoff existen para absorber eso.

Los falsos negativos aún existen. Las tareas fácticas de un solo paso, lints de una línea, ejecuciones del formateador, cualquier cosa que el modelo haya memorizado textualmente; todo esto se ejecuta más rápido solo con prompt. El benchmark debe enumerarlos honestamente para que el banco de trabajo no se presente como algo exagerado.

La conclusión no es "el harness gana para siempre". Los modelos absorben los trucos de harness con el tiempo. La conclusión es que hoy en día, la carga de ingeniería reside en las siete superficies, y los números lo demuestran.

Use It

Esta lección es el caso de estudio que citas cuando:

  • Alguien pregunta por que cada PR incluye un agent-rules.md y un contrato de alcance.
  • Un equipo quiere eliminar la barrera de verificación "solo para este sprint".
  • Se lanza un nuevo producto de agente y necesitas un benchmark portátil para saber si realmente ahorra tiempo.

Los números llegan más lejos que la explicación.

Ship It

outputs/skill-workbench-benchmark.md es un harness de evaluación portátil que ejecuta cualquier producto de agente a través de ambos pipelines contra la propia aplicación de ejemplo del proyecto e informa los cinco resultados.

Ejercicios

  1. Agrega un sexto resultado: tiempo hasta la primera edición significativa. ¿Cómo lo mides de forma limpia?
  2. Ejecuta la comparación en una tarea real de segundo día en tu base de código. ¿Dónde decaen los números del banco de trabajo?
  3. Agrega un pase de "falso negativo": tareas en las que solo con prompt habría sido más rápido y la sobrecarga del banco de trabajo es un costo real. Defiende mantener el banco de trabajo de todos modos.
  4. Reemplaza el "agente" programado con una llamada real a un LLM. ¿Qué resultados se vuelven más inestables?
  5. Escribe un resumen de una página dirigido a un no ingeniero. ¿Qué es lo que se conserva?

Términos clave

Término Lo que la gente dice Lo que realmente significa
Sample app "Repositorio de juguete" Pequeña pero lo suficientemente realista como para ejercitar las siete superficies
Pipeline "Flujo de trabajo" Secuencia ordenada de lecturas/escrituras de superficie que sigue el agente
Before/after report "Los recibos" El artefacto que le entregas a un escéptico
False negative "Exceso del banco de trabajo" Tareas en las que solo con prompt es más rápido; es útil enumerarlas honestamente
Workbench benchmark "Puntuación de confiabilidad" Harness portátil que ejecuta la comparación en tu base de código

Lectura adicional

0 lifetime access. Curriculum based on AI Engineering from Scratch by Rohit Ghumare (MIT, used under attribution).