Cómo auditar un PR de IA en 40 minutos

El 90% de los desarrolladores aceptan los Pull Requests generados por IA con un vistazo rápido al diff y un npm test que da verde. Un git merge directo a la rama principal y a otra cosa. El otro 10% sabe que ese atajo cuesta caro.

Cuando delegás la escritura de tu código en herramientas como Cursor, Claude Code o Lovable para levantar tu SaaS en cualquier framework moderno como Next.js o Angular, la sensación de avance es adictiva. Generás módulos enteros en minutos. Pero lo que la IA no te va a decir es que su lógica suele asumir un entorno perfecto: asume que las redes no tienen latencia, que los usuarios no ingresan datos maliciosos y que los sistemas externos responden siempre de manera predecible.

Hamel Husain explicó conceptualmente este problema en su artículo "Evals Skills for Coding Agents". Tomando esa base, adapté su framework de evaluaciones a la realidad concreta de un SaaS chico con tiempo limitado. La regla de oro en la ingeniería asistida por modelos de lenguaje es clara: si el agente escribe rápido, tu proceso de revisión tiene que ser sistemático.

El costo oculto de la velocidad algorítmica

Llevo casi 40 años escribiendo software. He visto paradigmas nacer y morir, lenguajes ponerse de moda y desaparecer, pero hay una constante que no cambia: la responsabilidad técnica sobre lo que llega a producción sigue siendo exclusivamente humana.

Un modelo estadístico no entiende tu modelo de negocio. No sabe si un registro duplicado en tu base de datos significa un error visual inofensivo o una pérdida directa de miles de dólares en facturación cruzada. Por eso, aceptar un PR a ciegas basándote en que "compila bien" es delegar el criterio técnico en una máquina que no va a pagar los costos del servidor cuando haya una fuga de datos.

Para evitar esto, tenés que implementar un filtro duro. No necesitas una suite de QA corporativa de seis semanas. Necesitas disciplina táctica.

Los 3 evals que tenés que correr antes de mergear

Este framework secuencial previene el 80% de los bugs críticos que llegan a producción por culpa de código autogenerado.

Eval 1 — Smoke test (5 min)

Acá validamos exclusivamente que lo básico no esté prendido fuego. No mires solo el diff en GitHub. Bajate la rama a tu entorno local.

Primero, verificás que npm test pase de verdad (linter limpio, typecheck estricto y tests unitarios básicos en verde). Y tené cuidado: revisá rápido que los tests unitarios que escribió la IA validen comportamiento real y no sean una obviedad inútil que solo testea si la función existe.

Si el PR toca una API: armás un curl crudo desde tu terminal, le mandás un payload real y verificás que te devuelva la estructura JSON esperada con el status code correcto.

Si el PR toca la UI: levantás el servidor local, hacés el flujo nuevo a mano simulando ser el usuario, y abrís la consola del browser para garantizar que no haya errores interrumpiendo el renderizado de la vista.

Eval 2 — Regression test (15 min)

El mayor peligro de un agente autónomo son los efectos colaterales. Como la IA tiene un contexto limitado, suele arreglar un archivo rompiendo otro que "no estaba mirando".

En este paso, verificás que los tests de otras features (no solo la que el PR dice implementar) corran sin romperse. Después, probás manualmente dos o tres flujos críticos de tu negocio que no deberían haber sido alterados: el proceso de signup, el login y el checkout principal.

El secreto técnico de este paso no es buscar errores de bulto, sino mirar atentamente los warnings en la consola. Los warnings son el lenguaje en el que el sistema te avisa de side effects (efectos secundarios, como un renderizado infinito o un event listener duplicado) que la IA introdujo silenciosamente sin dejarlos documentados.

Eval 3 — Security & data integrity (20 min)

El smoke y el regression test los hace casi cualquier dev con un poco de experiencia. El security test es el que TODOS saltean sistemáticamente por pereza. Y es exactamente de este paso omitido de donde salen los bugs que te queman la caja bancaria.

Acá tenés que ser abiertamente hostil con el código que generó la IA.

Forzá los inputs: mandale un input vacío en cada campo obligatorio. Mandale un input gigante (más de 10KB de texto crudo en un campo de descripción). Inyectale caracteres especiales y patrones SQL-like ('; DROP TABLE, <script>).

Si el código toca tu base de datos, frená y hacete tres preguntas: ¿El código respeta tu Row-Level Security (RLS) o se la está salteando usando un service role key por conveniencia algorítmica? ¿La operación necesita una transacción de base de datos para garantizar consistencia? ¿Si el proceso falla a la mitad, podría dejar datos huérfanos que corrompan el sistema?

Si el código toca infraestructura de pagos: ¿El endpoint valida criptográficamente la firma del webhook? ¿El proceso de guardado es idempotente o te va a duplicar los cobros si el evento llega dos veces? ¿Maneja correctamente el caso asíncrono y caótico donde "Stripe cobró la tarjeta perfectamente pero mi base de datos no se actualizó por un timeout de red"?

El cinturón de seguridad en sistemas reales

En FirmaLaboral tenemos 44 módulos operando en producción de manera concurrente. Cuando hay un PR listo, ya sea escrito por un humano o asistido por IA, pasa por una matriz parecida a esta pero bastante más estricta.

Al smoke, regression y security test, nosotros le sumamos validaciones sobre casos borde muy específicos de la liquidación de sueldos en AFIP y el procesamiento de cobros recurrentes a través de webhooks de Mercado Pago en nuestra base de MongoDB.

Ese cinturón de seguridad, que a simple vista parece burocrático y aburrido, es la razón exacta que explica nuestros casi 7 años operando en producción sin un downtime masivo. Las garantías de estabilidad en un entorno B2B crítico nunca vienen de escribir código más rápido; vienen de tener la disciplina para someter cada línea nueva a un escrutinio brutal.

Total: 40 minutos por PR de la IA. Suena mucho. Es menos que el costo de aceptar uno malo — un solo bug de pagos sin idempotencia te puede costar más que un mes entero de tu mejor dev trabajando en arreglar el desastre, devolver la plata y pedir disculpas a los clientes.

La velocidad de la IA generando código no sirve si no tenés un proceso para frenarla cuando va para el lado equivocado. 40 minutos por PR es el peaje de la velocidad.