Tener algo que asuma que el agente se equivocó y lo compruebe: tests que fallan primero, revisión que no la haga quien escribió, y controles que no se pueden saltear.
La idea que sobrevive a las herramientas
Sobre comportamiento nuevo, un test que nunca viste fallar no probó nada; y un revisor que nunca discute no está revisando.
Todas las disciplinas anteriores bajan la probabilidad de error. Esta es la única que lo detecta después de que ocurrió. Por eso no es opcional: es la red.
El primer problema es el orden. Si pedís los tests después de escribir el código, el agente escribe tests que pasan — es literalmente lo que le pediste. Un test escrito para confirmar código existente no puede fallar por la razón correcta: sobre comportamiento nuevo no prueba que el chequeo se daría cuenta si ese comportamiento faltara. El test tiene que existir antes y tenés que verlo fallar.
El segundo problema es quién revisa. El entrenamiento premia respuestas que a la gente le gustan, y a la gente le gusta tener razón. El resultado es un revisor que valida en vez de revisar. La solución no es pedirle que sea más crítico: es separar quién escribe de quién juzga, y darle al que juzga un criterio explícito en vez de pedirle una opinión.
El tercero es que la revisión termine. Un agente al que le pedís “revisá esto” va a seguir produciendo una cosa más mientras vos le sigas preguntando. La revisión no converge sola: sin un límite declarado de antemano, termina cuando te cansaste, que no es un criterio de calidad.
Cómo funciona, paso a paso
Hasta acá el porqué. Esto es la máquina: qué pasa en cada etapa y, sobre todo, cuál es la decisión que te toca a vos en cada una. Si en algún paso no decidís nada, ese paso lo está decidiendo la herramienta por vos.
01
Criterio
Qué pasa
Antes de que escriba una línea, existe una definición de qué significa que esté bien. Escrita, no pensada. Si no podés escribirla, todavía no sabés qué estás pidiendo.
Qué decidís vos
Redactarla. Es el único paso que no se delega, porque es el que define contra qué se va a medir todo lo demás.
02
Comprobación
Qué pasa
Ese criterio se convierte en algo que se ejecuta: un test, un tipo, una regla de linter. Una comprobación que corre distingue bien de mal sin opinar; una revisión a ojo, no.
Qué decidís vos
Que exista antes del cambio. Una comprobación escrita después confirma lo que el cambio hace, no lo que tenía que hacer.
03
Independencia
Qué pasa
Quien verifica no puede ser quien escribió. No es desconfianza: el mismo hilo que produjo el código ya tiene todos los motivos por los cuales está bien, y los va a encontrar de nuevo.
Qué decidís vos
Separar los roles. Un agente revisando su propia salida te devuelve una aprobación bien redactada.
04
Compuerta
Qué pasa
Cada comprobación corre en un punto concreto del camino: al terminar, antes del commit, antes del push, antes del release. La misma comprobación en el lugar equivocado no protege nada.
Qué decidís vos
Dónde va cada una. Lo rápido corre local y todo el tiempo; lo lento corre una vez, más adelante.
05
Evidencia
Qué pasa
De la verificación queda un rastro atado al contenido exacto que se verificó. Si el contenido cambia, la evidencia deja de valer — y esa es toda la diferencia entre verificar y haber verificado alguna vez.
Qué decidís vos
Que la evidencia sea del contenido y no de la intención. “Ya lo revisé” no es evidencia de nada.
Señales de que te falta
Todo en verde y la funcionalidad no anda.
Le decís que se equivocó y te da la razón aunque vos estés mal.
El mismo agente escribe el código y lo aprueba.
Las revisiones no terminan: siempre aparece otra observación.
Errores comunes al cubrirla
Pedir los tests al final. Solo confirman lo que ya está escrito.
Usar al autor como revisor. Nunca va a encontrar su propio punto ciego.
Revisión sin límite: se vuelve infinita y deja de ser una señal.
Ninguna es obligatoria. Lo obligatorio es cubrir la disciplina; estas son formas conocidas de hacerlo.
Skills for Real Engineers
Matt PocockPaquete
Colección de procedimientos armada alrededor de las fallas concretas del desarrollo asistido.
Problema, mecanismo y encaje
El dolor concreto
Los procedimientos genéricos no sirven de mucho. Estos atacan fallas con nombre: que entendió otra cosa de la que pediste, código con bugs, arquitectura que se degrada sola.
Cómo funciona
Procedimientos que te interrogan antes de codear para alinear qué se va a construir, arman un archivo con el vocabulario del dominio, imponen ciclos de test-primero, y aplican un método estructurado para diagnosticar bugs.
Cuándo conviene
Cuando ya tenés el entorno andando y el problema pasó a ser la disciplina, no la capacidad. La idea de fondo —acordar el vocabulario del dominio antes de escribir código— vale aunque no instales nada.
Hooks
Patrón del ecosistemaPatrón
Comandos deterministas que se ejecutan en momentos definidos, sin pasar por el modelo.
Problema, mecanismo y encaje
El dolor concreto
Pedirle al modelo que “siempre corra el linter antes de commitear” es una sugerencia. A veces la cumple. En algo innegociable, a veces es igual que nunca.
Cómo funciona
El entorno ejecuta un comando en un punto del ciclo —antes de una acción, al iniciar sesión, al terminar— y usa su salida. Como no pasa por el modelo, no admite interpretación ni olvido.
Cuándo conviene
Para todo lo que tenga que pasar siempre. Si lo describirías como “sin excepción”, va en un hook y no en un prompt.
También ayuda en
OpenSpec
Fission AIFlujo de trabajo
Método
Desarrollo guiado por especificación en archivos: lo que ya está acordado, separado de lo que se está proponiendo.
Gentle AI
Gentleman ProgrammingFlujo de trabajo
Método
Instalador reproducible de configuraciones, desarrollo por fases guiado por especificación, y revisión con presupuesto.
gstack
Garry TanFlujo de trabajo
Método
Más de veinte procedimientos que reparten roles de producto —producto, diseño, QA, release— sobre un ciclo de sprint.