Doce Acuerdos de Trabajo para Código Escrito por Máquinas

La retro fue la parte fácil.

Tu equipo realizó la retro de resaca del vibe-coding. Los datos de churn estaban en el tablero, la sala estuvo de acuerdo en que la cola de revisión había estado racionándose silenciosamente, y todos se fueron con esa rara sensación post-retro de haber decidido algo. Dos sprints después, los acuerdos viven en un documento resumen que nadie abre, y el gráfico de churn no ha notado nada.

Ese modo de falla está bien documentado: alrededor de dos tercios de los elementos de acción de retrospectivas mueren sin cambiar nada. Los acuerdos de trabajo mueren más rápido, porque un acuerdo es una norma, y una norma no obtiene número de ticket ni propietario a menos que se lo des.

Esta es la mitad del manual de reglas de la retro de resaca. Doce acuerdos de trabajo para equipos que envían código escrito por máquinas, construidos a partir de la misma investigación pública que nombró el problema. Los tres ejemplos de la publicación original están aquí, acompañados por nueve más, todos en el mismo formato: una regla que el equipo puede enunciar en una oración, el número que se mueve cuando se sigue la regla, y el check-in donde lo revisas.

¿Qué Es un Acuerdo de Trabajo para Código Escrito por Máquinas?

Un acuerdo de trabajo para código escrito por máquinas es una regla que un equipo escribe para sí mismo sobre cómo se producen, revisan y apropian los cambios generados por IA. Difiere de una política tanto en origen como en aplicación: una política se impone desde arriba y se audita, mientras que un acuerdo de trabajo se negocia en una retrospectiva, se verifica contra los datos de entrega del propio equipo, y se reescribe cuando esos datos dicen que no está funcionando.

El caso de investigación para ellos es directo. El informe 2025 de DORA encontró que el 90% de los desarrolladores ahora usan IA en el trabajo, con la adopción vinculada positivamente al throughput y negativamente a la estabilidad de entrega. Su Modelo de Capacidades de IA identifica qué separa a los equipos que la IA amplifica de los equipos que desestabiliza, y cada capacidad en la lista es organizacional: una postura de IA clara y comunicada, lotes pequeños, prácticas sólidas de control de versiones. Un acuerdo de trabajo es la unidad más pequeña de postura organizacional — una oración a la que todo el equipo ha acordado ser responsable.

Una Regla, un Número, un Check-In

La mayoría de los acuerdos de trabajo fallan estructuralmente, no culturalmente. Les falta una de tres partes.

La regla tiene que caber en una oración que un compañero de equipo pueda enunciar en frío. Si toma un párrafo, es orientación, y la orientación pierde contra una fecha límite cada vez.

El número hace que la regla sea falsable. La verificación es exactamente donde la intuición engaña: la encuesta 2025 de Stack Overflow de más de 49,000 desarrolladores encontró que la principal frustración con las herramientas de IA, citada por el 45%, es código que está "casi bien, pero no del todo" — y el código casi-bien se siente bien hasta que producción no está de acuerdo. Los sentimientos no arbitran eso. Los números sí.

El check-in le da al número una fecha y un lugar, usualmente los primeros cinco minutos de la próxima retro. Una regla sin un número es una opinión. Un número sin un check-in es papel tapiz.

Los Doce

Roba libremente. Los números en las reglas (400 líneas, 90 días, dos tareas) son puntos de partida para ajustar, no leyes.

La Revisión Se Está Racionando a Sí Misma. Raciónala a Propósito.

La telemetría de Faros AI de 2026 en 22,000 desarrolladores encontró que el tiempo medio hasta la primera revisión aumentó 156.6% y los PRs fusionados sin revisión alguna aumentaron 31.3%. Cuando la capacidad de revisión se agota, los equipos no deciden omitir la revisión — ella se decide sola, un "se ve bien" a la vez.

1. "Nada se fusiona sin una aprobación humana, CI verde o no." El acuerdo base. Casi un tercio más de cambios ahora llegan a producción sin que un solo humano los lea, y el código casi-correcto es precisamente el tipo que pasa CI. Verifica: conteo de fusiones sin revisión, semanalmente.

2. "Los PRs escritos por máquina de más de 400 líneas se dividen antes de la revisión." Los lotes pequeños son la capacidad más importante en el modelo de DORA, y el tamaño del lote es la entrada que un equipo controla más directamente. Un revisor puede sostener 400 líneas honestamente; nadie sostiene 2,000. Verifica: distribución de tamaño de PR, próxima retro.

3. "Los cambios que tocan autenticación, pagos o migraciones de datos obtienen un segundo revisor, sin importar quién fue el autor." Escala la verificación con el radio de explosión, no con la confianza en la herramienta. Las rutas críticas son donde tus incidentes ya se agrupan; nómbralas explícitamente en el acuerdo. Verifica: tasa de dos aprobaciones en PRs de rutas críticas, próxima retro.

La Responsabilidad Sobrevive al Autocompletado

El módulo que nadie quiere tocar tiene un autor que no puede explicarlo. Estos dos acuerdos mantienen que la autoría signifique algo.

4. "Si no puedes explicar el diff, no puedes fusionarlo." La explicación es la verificación más barata disponible: cuesta diez minutos y atrapa la clase de bug que la revisión pasa por alto. Si explicar un cambio toma más tiempo que regenerarlo, esa es información sobre el cambio. Verifica: en la preparación de demo, un PR fusionado escrito por máquina por ingeniero se explica en voz alta, cada sprint.

5. "La descripción del PR registra lo que el humano verificó, no lo que el modelo generó." "Ejecuté la migración localmente, probé el rollback, revisé el plan de consulta" le dice a un revisor dónde fue la atención humana. El reporte ROI 2026 de DORA llama al costo de verificar la salida de la máquina el impuesto de verificación; esta línea hace que el impuesto sea visible en lugar de ambiental. Verifica: proporción de PRs fusionados con una nota de verificación, próxima retro.

Los Cambios Son la Métrica Honesta de Velocidad

Los cambios de código aumentaron 861% en los datos de Faros. Una característica que se entregó dos veces no fue rápida la primera vez, sin importar lo que dijo el reporte del sprint.

6. "Una reescritura dentro de 90 días es retrabajo, y el retrabajo obtiene un ticket." La ventana de 90 días viene del patrón que Autonoma llama el ajuste de cuentas de 90 días: la velocidad del mes uno convirtiéndose en deuda del mes tres. El retrabajo que nunca aparece en el rastreador es un costo que el equipo paga pero nunca cuenta. Verifica: tickets de retrabajo y tasa de cambios por módulo, próxima retro.

7. "El código desechable se declara desechable al nacer." Los spikes y prototipos son un uso legítimo de la velocidad de AI. Etiquétalos cuando se crean, para que las estadísticas de cambios se mantengan honestas y ningún spike sea promovido a producción porque todos olvidaron qué era. Verifica: proporción de cambios provenientes de spikes etiquetados, mensualmente.

Los Incidentes Son Donde el Impuesto Se Cobra

Proporción de incidentes a PR: aumentó 242.7%. Bugs por desarrollador desde la adopción: aumentó 54%. La verificación que omites en el momento de la revisión se realiza en producción, a la peor tarifa por hora posible.

8. "Cada revisión de incidente pregunta si el cambio desencadenante fue escrito por máquina, y rastreamos la proporción." No para culpar — la proporción reemplaza la anécdota más ruidosa en la sala con el propio número del equipo, y es el número que te dice si los acuerdos 1 al 5 están funcionando. Verifica: campo de plantilla de postmortem; proporción revisada mensualmente.

9. "Un humano es dueño de cada aserción de prueba." AI escribe pruebas plausibles de la manera en que escribe código plausible, y una prueba que no afirma nada es peor que ninguna prueba, porque compra confianza sin comprar verificación. Redactar pruebas es delegable. Decidir qué debe ser verdad no lo es. Verifica: conteo de bugs escapados, próxima retro.

No Inundes la Cola

10. "Dos tareas de agente en curso por persona, máximo." La velocidad de escritura solía ser un límite natural de trabajo en progreso; los agentes lo eliminaron. Un ingeniero ahora puede abrir PRs más rápido de lo que tres pueden revisarlos, y el desbordamiento se convierte en latencia de revisión o fusiones sin revisar — los mismos dos números que ya se mueven en la dirección equivocada. Un límite WIP en la delegación mantiene solvente el presupuesto de verificación humana. Verifica: PRs abiertos por autor, semanalmente.

Acuerdos Sobre los Acuerdos

Los últimos dos existen porque los primeros diez de otro modo se unirán a los dos tercios de elementos de acción que mueren.

11. "Cada acuerdo lleva una fecha de vencimiento." Tres sprints es un valor predeterminado sensato. Al vencimiento, el equipo vuelve a votar: mantener, reescribir o retirar. Un acuerdo que se renueva automáticamente para siempre es una política disfrazada, y una lista llena de reglas muertas le enseña al equipo que la lista es decoración. Verifica: la lista activa y sus edades, cada retro.

12. "La retro abre con el tablero de puntuación." Primeros cinco minutos, antes de nuevos temas: cada acuerdo activo, su número y si se movió. Este es el ciclo entregando y quedándose en lugar de entregando y evaporándose. Verifica: es el primer elemento de la agenda, cada retro.

Etiqueta el Código, Nunca al Programador

Varios de estos acuerdos rastrean si un cambio fue escrito por máquina. Ninguno de ellos rastrea quién se apoyó en el modelo, y la distinción sostiene todo el sistema. Los datos a nivel de cambio describen cómo el proceso del equipo maneja un nuevo tipo de código. Los datos a nivel de persona se convierten en una tabla de clasificación, y una tabla de clasificación corrompe cada número que muestra: en el momento en que los ingenieros sospechan que la proporción de incidentes alimenta una evaluación de desempeño, dejan de etiquetar honestamente, y la retro vuelve a funcionar con intuiciones.

Este es el mismo argumento que hemos hecho sobre medir el impacto de la IA en general: mide resultados a nivel de equipo, nunca actividad a nivel de persona. Los acuerdos anteriores solo funcionan porque todos en la sala saben que los números juzgan el proceso, no a las personas.

Cómo Adoptar Estos Sin Matarlos

Adopta dos o tres, no doce. Un equipo que sostiene doce reglas nuevas no verifica ninguna; el menú existe para que puedas emparejar acuerdos con tus propios peores números.

• Comienza desde tus datos, no desde esta publicación. Si la rotación está estable pero los incidentes están aumentando, quieres 8 y 9, no 6 y 7. Extrae los números antes de la retro y deja que ellos elijan.
• Vota en la retro. Un acuerdo impuesto por un gerente es una política disfrazada — obtiene cumplimiento, no apropiación. El equipo que escribió la regla es el equipo que la defiende bajo presión de fecha límite.
• Registra la línea base en la adopción. "Fusiones sin revisión: 14 el sprint pasado" convierte la primera verificación en una comparación en lugar de un debate. ¿Sin línea base? Entonces encontrarla es el primer elemento de acción.
• Dale a cada acuerdo un responsable. No un ejecutor — un reportero. Una persona trae el número a la retro para que el marcador nunca dependa de la memoria colectiva.

Preguntas Frecuentes

¿Cuántos acuerdos de trabajo debería tener un equipo a la vez?

Dos o tres acuerdos activos a la vez. Cada uno necesita un número extraído, una verificación realizada y un responsable reportando, y ese presupuesto de atención se agota rápido. Los equipos que adoptan una lista larga no verifican nada; los equipos que adoptan tres y los retiran o reemplazan al vencimiento construyen el hábito que hace que los siguientes tres sean baratos.

¿Deberían etiquetarse los pull requests como generados por IA?

Sí, a nivel de cambio — una etiqueta o una nota en la descripción del PR es suficiente para hacer computables las proporciones de rotación e incidentes. Nunca a nivel de persona: el rastreo de uso de IA por ingeniero corrompe los datos que recopila, porque las personas manipulan lo que sea que se observe. La pregunta útil es cómo el proceso maneja los cambios escritos por máquina, no quién los produjo.

¿Qué pasa si el número no se mueve?

Entonces la verificación funcionó. O la regla no se siguió, lo que usualmente significa que era demasiado costosa como estaba escrita y necesita renegociación, o se siguió y no ayudó, lo que significa retirarla y gastar la atención en otro lugar. Un acuerdo que puede fallar visiblemente es el único tipo que puede tener éxito de manera creíble.

¿Funcionan estos sin sprints?

Sí. Las verificaciones se adjuntan a cualquier ritmo de reflexión que tenga el equipo — semanal, por lanzamiento, o impulsado por eventos. La cadencia importa menos que el lugar: un momento recurrente donde los números están en el tablero y el equipo tiene permitido cambiar las reglas.

La Conclusión

El argumento de la retro de resaca era que la deuda de código por intuición es una falla de proceso, y la retrospectiva es donde el proceso se renegocia. Esta es la otra mitad: lo que sale de esa sala tiene que ser falsificable, o la siguiente retro lo re-argumenta desde cero. Los equipos que superan la resaca no son los que tienen las reglas de IA más estrictas o las más flexibles. Son los que escriben reglas que pueden perder un argumento con los datos — y las dejan perder.

Roba tres. Establece el vencimiento. Abre la siguiente retro con el marcador.

Fuentes

• Faros AI — "Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash" (abril de 2026)
• DORA — State of AI-assisted Software Development 2025 (septiembre de 2025)
• DORA AI Capabilities Model (2025)
• InfoQ — "New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment" (mayo de 2026)
• Stack Overflow — 2025 Developer Survey results (diciembre de 2025)
• Autonoma — "Vibe Coding Technical Debt: The 90-Day Reckoning" (abril de 2026)

Lectura Adicional

• The Retro for the Vibe-Coding Hangover — la retrospectiva de la que sale este manual de reglas.
• Why 2/3 of Retrospective Action Items Die (And How to Fix It) — la mecánica de seguimiento detrás de los acuerdos 11 y 12.
• Measuring What AI Actually Does to Your Team — el argumento de medición a nivel de equipo, neutral a la IA, en su totalidad.
• Ship and Stick: How to Measure Whether AI Is Actually Working — el estándar de resultado en el que cierra el marcador.