La auditoría: aprobar el código del agente sin volverse sello
El agente escribe código que pasa todos los tests automáticos y aun así puede estar haciendo lo equivocado. Esta lección te da un checklist de auditoría de cinco ítems para quien aprueba PR de agente a escala, y el principio de que quien aprueba es siempre quien responde.
Un agente abrió un PR para corregir un bug de paginación. Los tests pasaron, el lint pasó, el build pasó, todo verde. El revisor le echó un vistazo al resumen automático, le pareció razonable, hizo clic en approve en quince segundos. Solo después, en una investigación de otro bug, alguien notó que el PR también había alterado un valor de caché por defecto en un archivo de configuración que no tenía nada que ver con paginación. Nadie lo había notado, porque nadie había leído el diff entero.
Un agente redacta una minuta de adenda contractual, citando la cláusula original y el cambio propuesto. El abogado aprueba rápido porque el texto está bien escrito y formateado en el estándar del estudio, sin abrir el contrato original para comparar línea por línea. Solo cuando el cliente pregunta por qué una cláusula de confidencialidad desapareció de la adenda alguien nota que el agente reescribió toda la sección en vez de solo insertar el cambio, y la cláusula que debía haberse preservado ya no estaba ahí.
Un agente prepara el paquete de evaluación de desempeño de doce personas, con nota, justificación y recomendación de aumento, a partir de los registros del ciclo. El gerente aprueba el paquete entero en una tarde, porque el formato está impecable y las justificaciones suenan plausibles. Después, una persona cuestiona su nota: la justificación citaba un proyecto que nunca lideró, un dato que el agente tomó equivocadamente de otro colaborador con nombre parecido, y que nadie verificó antes de aprobar todo el paquete de una vez.
Un agente escribe el PRD de una feature nueva, con criterio de éxito, alcance y una tabla de esfuerzo estimado. El PM aprueba el documento porque la estructura está redonda y el criterio parece razonable, sin verificar la fuente de cada número. Solo en la reunión de planificación alguien pregunta de dónde salió la estimación de esfuerzo, y nadie sabe responder: el agente extrapoló de una feature "parecida" que en realidad era bastante más simple, y el equipo se compromete con un plazo que ya nació roto.
Un agente arma la propuesta comercial para un cliente grande, con descuento, plazo y cláusula de reajuste, tomando del historial de propuestas anteriores. El gerente comercial aprueba rápido, porque el formato es el de siempre y el descuento parece dentro de la política. Solo cuando el cliente firma alguien nota que la cláusula de reajuste anual había sido copiada de un contrato de otro segmento, con una condición que la empresa nunca practica con ese tipo de cliente, y ahora está firmada.
Un agente ajusta el ruteo de un proceso logístico después de identificar un cuello de botella, y presenta el nuevo flujo con la métrica de SLA proyectada. El gerente de operaciones aprueba el cambio porque el número proyectado es bueno y el informe está bien escrito, sin probar el flujo nuevo en una muestra pequeña antes. En la primera semana en producción, el nuevo ruteo aumenta el costo por entrega en 15%, porque el agente había ignorado una restricción de capacidad de uno de los centros de distribución que no estaba documentada en la base que usó.
Un agente prepara el informe de cumplimiento de controles para el comité de riesgo, marcando la mayoría de los ítems como conformes. El responsable de compliance aprueba el informe entero porque el formato sigue el estándar de siempre y ningún ítem llamó la atención a primera vista. En una auditoría externa meses después, se descubre que un control crítico había sido marcado como conforme con base en una evidencia de un ciclo anterior, que el agente reusó porque "parecía actual", y nadie verificó la fecha antes de aprobar.
Un agente ajusta el flujo de registro en el prototipo de Figma después de un test de usabilidad, y presenta el antes y después con la métrica de finalización proyectada. El diseñador responsable aprueba el cambio porque el mockup parece una evolución obvia, sin probarlo de nuevo con usuario real. Al subir a producción, el cambio resuelve el problema que motivó el ajuste, pero introduce uno nuevo: el campo que el agente movió hacia arriba de la pantalla rompe el orden de tabulación para quien navega solo con teclado, un problema que solo aparece en una auditoría de accesibilidad, semanas después.
Un agente arma el informe trimestral de posicionamiento competitivo para el directorio, cruzando dato de mercado con el CRM interno. El documento sale formateado, con gráfico y fuente citada, y el ejecutivo que lo revisa aprueba en cinco minutos porque "los números coinciden con lo que esperaba". Solo en una reunión de seguimiento, un analista nota que el gráfico de participación de mercado sumaba dos recortes de segmento distintos, inflando el número en ocho puntos, un error que nadie detectó porque nadie abrió la planilla de origen antes de aprobar el slide que fue al directorio.
Oye, déjame contarte una escena que ya debe haber pasado en tu equipo. Un agente abre un PR, todo el pipeline queda verde, el resumen automático parece razonable, y el botón de aprobar está ahí, pidiendo un clic. Haces clic. Pasas al siguiente. Al final del día aprobaste veinte PRs y no podrías recordar qué había en ninguno de ellos. Esta lección trata sobre el momento exacto en que aprobar dejó de ser revisión y se volvió sello.
La idea central de esta lección. Los portones automáticos que viste en la lección 6.1 ya frenan parte de esto: test, lint y build verdes garantizan que el código hace lo que los checks verifican. Lo que no garantizan es que el código hace lo correcto, que quedó dentro del alcance pedido, y que no abrió una puerta que nadie pidió abrir. Por eso existe una capa arriba del portón automático: el criterio de quien aprueba. Esta lección te da un checklist de cinco ítems para esa capa, y un principio que no tiene excepción: quien aprueba el PR es quien responde por lo que rompe. El agente no firma nada. Tú firmas.
01"Pasó los tests" no es lo mismo que "está correcto"
Vale la pena entender la diferencia desde la raíz, porque cambia cómo miras el verde del pipeline. Un test automatizado verifica algo específico que alguien escribió antes: esta función devuelve este valor, esta ruta responde con este código, esta pantalla se renderiza sin romperse. Es una pregunta cerrada, y el test le responde sí o no.
El problema es que un agente puede escribir un código que responde sí a todas las preguntas cerradas que existen, y aun así estar equivocado de un modo que nadie pensó en probar. Resuelve el bug pedido, pero también toca un archivo de configuración que no tenía nada que ver con el pedido. Corrige el mensaje de error, pero también invierte el orden de dos verificaciones de seguridad. El test que existía sigue verde, porque nunca fue diseñado para detectar ese tipo de desvío. El portón automático de la lección 6.1 es real y funciona, solo que frena únicamente lo que alguien ya sabía que necesitaba frenarse.
02Por qué aprobar a escala se vuelve sello
Aquí vive el riesgo del que nadie habla en voz alta. Cuando el volumen de PR de agente sube, el revisor se cansa. El patrón se repite: abre, mira el resumen, ve el verde, aprueba. En la vigésima vez del día, el cerebro ya decidió que "esto siempre pasó antes", y el clic en aprobar se vuelve reflejo, no criterio.
Es exactamente el mecanismo de la salvedad mortal que ya apareció en esta trilla: velocidad sin revisión se convierte en deuda e incidente. Solo que aquí tiene una cara específica, la del sello. Sello es cuando la aprobación dejó de verificar algo y pasó a solo confirmar que se siguió el proceso. Y lo peor es que el sello se siente exactamente igual a una revisión de verdad, por dentro. Nadie nota que se convirtió en sello hasta que aparece el incidente.
03El checklist de auditoría de cinco ítems
Aquí está el centro de la lección. Cinco preguntas, en orden, antes de que cualquier PR de agente salga aprobado con tu nombre. Piénsalas como un embudo: cada una filtra un tipo de riesgo, y lo que sobrevive a las cinco es un PR que puedes defender de verdad.
La primera: ¿el diff coincide con la intención descrita en el ticket? Lee el pedido original y lee el diff, y verifica si uno está contenido en el otro. Si el PR hace más de lo que el ticket pedía, ese sobrante necesita una explicación, no una suposición.
La segunda: ¿el radio de acción es el esperado? Mira la lista de archivos modificados antes de mirar el contenido. Un PR de "corregir paginación" que también toca un archivo de configuración de caché es exactamente el tipo de desvío que este ítem detecta.
La tercera: ¿el PR tocó secreto, permiso, credencial o dato sensible? Esta pregunta sola ya habría detectado el ejemplo de seguridad del inicio de la lección, donde el orden de dos verificaciones de permiso fue invertido sin que ningún test lo cubriera.
La cuarta: ¿el test cubre el caso real o solo el camino feliz? Pregunta qué pasaría si el input fuera malo, si el sistema estuviera bajo carga, si la dependencia cambiara de comportamiento. Si la respuesta es "no sé", el test verde no prueba nada más allá del camino fácil.
La quinta, y la más importante: ¿logras defender ese PR en una reunión, línea por línea, si te cuestionan? Si la respuesta es "no, lo hizo el agente", el PR no está listo para aprobación. Aprobación sin defensa posible es aprobación huérfana.
Sabe más: por qué el ítem 5 (defensa) es el más fuerte de los cinco
Los ítems 1 a 4 son verificaciones objetivas, se pueden hacer en minutos y casi siempre detectan el desvío obvio. El ítem 5 es distinto: es una prueba de honestidad sobre ti mismo. Si imaginas una reunión difícil, con tu nombre en el PR y alguien preguntando "por qué esta línea 340 cambió el valor de timeout", y la única respuesta que te viene a la cabeza es "no sé, lo decidió el agente", esa es la señal más confiable de que la aprobación fue un sello. Este ítem funciona incluso cuando no sabes exactamente qué buscar en los otros cuatro, porque no depende de encontrar el error, depende de que te admitas a ti mismo que no miraste de verdad. Es el ítem que sobrevive incluso cuando tu conocimiento técnico específico de ese fragmento es limitado, porque la pregunta no es "esto está correcto", es "sé lo suficiente para decir que lo está".
04La regla de tres tiempos: el agente propone, el portón verifica, la persona aprueba
El checklist tiene un principio detrás, y es lo que sostiene todo. Piensa en una regla de tres tiempos que nunca colapsas en uno solo.
El agente propone. Es rápido e incansable, y el PR que entrega ya viene con el borrador listo, muchas veces bueno. Usa esa velocidad con confianza, es donde el agente brilla.
El portón automático verifica. Es lo que ya viste en la lección 6.1: test, lint, build. Es objetivo y no acepta lo que no pasó, y lo hace sin cansarse, sin saltarse línea, sin cara de sueño el viernes a las 18h.
Y la persona aprueba, de verdad. Este es el paso que el checklist de cinco ítems completa. Aprobar de verdad no es lo mismo que hacer clic en "approve" después de ver el ícono verde. Es correr las cinco preguntas y lograr responder cada una. Saltarse ese paso es exactamente lo que hace que un PR equivocado, con test verde, casi se convierta en incidente en producción.
05Quien aprueba responde, siempre
Cierra el razonamiento con el punto que no tiene medias tintas. Cuando un PR rompe algo en producción, o planta una deuda que solo aparece meses después, la pregunta que importa no es "quién escribió esa línea". Es "quién aprobó". Y la respuesta siempre es un nombre humano.
"Lo hizo el agente" no existe como excusa, del mismo modo que no existe en finanzas ni en ningún otro lugar de esta trilla. El agente no va a la reunión de post-mortem. El agente no pierde la confianza del equipo. El agente no es quien le explica al cliente por qué el sistema estuvo fuera de servicio cuarenta minutos. Quien aprobó ese PR es quien carga con eso, porque aprobar es exactamente el acto de decir "yo verifiqué, esto puede subir".
Esto no es desconfianza del agente, es higiene de quien opera a escala. El agente te devuelve horas de trabajo mecánico. El checklist de cinco ítems es el precio pequeño que protege esa ganancia: minutos de auditoría contra un incidente que cuesta una noche de trabajo, una conversación difícil y un pedazo de la confianza del equipo. Aprobar de verdad es lo que transforma la velocidad de agente en velocidad segura de usar.
Hazlo ahora
Toma un PR real de agente que aprobarías hoy solo porque los tests pasaron, tu tu tarea real u otro PR reciente de tu cola. Corre el checklist de cinco ítems en él, escribiendo una línea de respuesta para cada uno:
- ¿El diff coincide con la intención descrita en el ticket o en el pedido original?
- ¿El radio de acción es el esperado, o el PR tocó archivo o módulo fuera del alcance?
- ¿El PR tocó secreto, permiso, credencial o dato sensible?
- ¿El test cubre el caso real (carga, input malo, dependencia cambiando) o solo el camino feliz?
- ¿Logras defender ese PR en una reunión, línea por línea, si te cuestionan mañana?
Al final, decide: ¿todavía aprobarías ese PR tal como estaba, o necesita otra mirada antes? Si la respuesta cambió después del checklist, acabas de sentir la diferencia entre sello y auditoría.
Practica
1. Un PR de agente pasó todos los tests automatizados, el lint y el build. ¿Qué garantiza eso?
2. ¿Por qué aprobar PR de agente en alto volumen tiende a volverse sello?
3. Un PR de agente aprobado por ti derrumba un servicio en producción. ¿Quién responde por eso?
Para la pizarra
Sobre el verdepasó los tests no es lo mismo que está bien.
Sobre el sello de gomalo peor del sello es que por dentro se siente como revisión.
Sobre quién respondequien aprueba responde por lo que se rompe. Por eso la aprobación tiene que ser criterio, no clic.
Gracias por el feedback. Esto ayuda a afinar la próxima lección.