La programación por sensaciones ha cambiado quién puede producir una aplicación con apariencia funcional. Un prompt puede generar pantallas, conectar una API y ensamblar un flujo de trabajo plausible antes de que un equipo tradicional de ingeniería haya terminado su primera revisión de diseño.

Esa velocidad crea un nuevo problema de contratación y entrega: una demo ya no es una evidencia sólida de que el software sea bueno. Los empleadores harán cada vez más una pregunta difícil: ¿puede este sistema construido con IA comportarse correctamente cuando las entradas son desordenadas, las dependencias fallan, los usuarios repiten acciones y el modelo subyacente cambia?

La respuesta vendrá de un estándar de calidad que se parece menos al pulido visual y más a la verificación disciplinada del software. Las personas que destaquen no se limitarán a mostrar lo que produjo una herramienta de programación con IA. Mostrarán cómo lo probaron, qué no puede hacer de forma segura y cómo saben que un cambio no rompió otra cosa.

Un benchmark es evidencia, no una puntuación de clasificación

Los benchmarks de agentes de programación de código abierto ofrecen puntos de partida útiles, pero miden capacidades diferentes. SWE-bench usa problemas reales de GitHub e instantáneas de repositorios, lo que lo hace relevante para el trabajo de mantenimiento. Terminal-Bench evalúa la interacción con la línea de comandos. Otros benchmarks mencionados, incluidos SlopCodeBench y ProgramBench, se enfocan en distintos aspectos del código generado y del comportamiento de los agentes.

Esos benchmarks pueden ayudar a comparar herramientas o establecer una línea base, pero los empleadores deben tener cuidado de no tratar una sola puntuación como prueba de preparación para producción. Un modelo que resuelve problemas de repositorios aún puede producir una lógica de autorización insegura. Un agente que completa tareas de terminal puede no conservar el estado a lo largo de un flujo de trabajo extenso. Una aplicación web pulida puede superar una demo por el camino feliz y aun así gestionar mal los reintentos o los pagos duplicados.

Por lo tanto, un portafolio o una revisión interna creíble debería incluir un conjunto de evaluación específico para la tarea. El conjunto podría contener informes de errores representativos, recorridos normales de usuario, entradas malformadas, límites de permisos, fallos de dependencias y regresiones corregidas anteriormente. Cada caso debería tener un resultado esperado explícito, no simplemente una captura de pantalla que se vea bien.

El paquete mínimo de pruebas para software construido con IA

Para una aplicación pequeña, se puede crear un paquete de calidad útil sin un laboratorio de investigación sofisticado:

  • Pruebas de aceptación: verifican el comportamiento visible para el usuario en los flujos de trabajo más importantes, incluidos los resultados exitosos y no exitosos.
  • Pruebas unitarias y de integración: comprueban las reglas de negocio de forma aislada y confirman que las bases de datos, las API, las colas y la autenticación funcionen juntas según lo previsto.
  • Pruebas negativas: envían entradas faltantes, malformadas, demasiado grandes, duplicadas y no autorizadas. El código generado por IA suele verse más sólido en el camino mostrado en el prompt, por lo que los caminos no solicitados son importantes.
  • Pruebas de regresión: convierten cada defecto descubierto en una prueba permanente. Una demo exitosa después de una corrección no es suficiente si el mismo fallo puede regresar en el siguiente cambio generado.
  • Comprobaciones de seguridad: prueban el control de acceso, el manejo de secretos, las defensas contra inyecciones, las vulnerabilidades de dependencias y si el contenido no confiable puede influir en llamadas a herramientas o acciones privilegiadas.
  • Comprobaciones operativas: verifican los tiempos de espera, los reintentos, la idempotencia, los registros, las alertas y el comportamiento seguro cuando una dependencia no está disponible.

Esto se acerca a la mentalidad de ingeniería de QA descrita en el relato de Stack Overflow sobre un ciclo de vida agéntico del desarrollo de software. El cambio importante es cultural: el aseguramiento de la calidad no es una inspección final después de que una IA haya escrito el código. Es la estructura que hace que la generación rápida sea lo bastante segura para utilizarla.

Prueba la orquestación, no solo el resultado

Cuando el software incluye un agente de IA, las pruebas habituales de la aplicación son necesarias, pero insuficientes. El sistema puede fallar porque el modelo interpretó mal una solicitud, pero también puede fallar porque la orquestación circundante perdió el contexto, llamó dos veces a una herramienta, aceptó una salida estructurada malformada o nunca terminó.

Las áreas de regresión previas al despliegue recomendadas en el resumen son una lista de comprobación práctica: pérdida de contexto, idempotencia de herramientas, inyección de prompts, salida estructurada, falta de terminación, fundamentación de la recuperación y rehidratación del estado. Estas son propiedades de ingeniería que se pueden probar.

Por ejemplo, una prueba puede ejecutar la misma solicitud dos veces y confirmar que el segundo intento no cree un pedido duplicado. Otra puede interrumpir a un agente a mitad de un flujo de trabajo, reiniciarlo y verificar que reanude desde un estado válido en lugar de repetir una acción irreversible. Una prueba de recuperación puede exigir que el sistema cite o devuelva únicamente información de un conjunto de fuentes aprobado. Una prueba de salida estructurada puede proporcionar una respuesta inválida y confirmar que la aplicación la rechace de forma segura en lugar de tratarla silenciosamente como datos válidos.

Los sistemas de larga duración y los multiagente necesitan registros de fallos especialmente claros. Los investigadores trabajan en la atribución automatizada de fallos porque puede ser difícil identificar qué agente causó un fallo y en qué momento de una larga cadena de interacción. En términos prácticos, los equipos deberían conservar las llamadas a herramientas, las entradas, las salidas, las versiones de los modelos, las marcas de tiempo, las transiciones de estado y las decisiones finales en un registro de auditoría que tenga en cuenta la privacidad. Sin esa evidencia, una prueba en rojo te indica que algo falló, pero no por dónde empezar a corregirlo.

La reproducibilidad se convertirá en una ventaja profesional

El código generado por IA es variable. Una nueva ejecución puede producir una implementación diferente; una actualización del modelo puede cambiar el comportamiento; una interrupción del proveedor puede alterar el enrutamiento o la latencia. Por lo tanto, los empleadores valorarán a los candidatos que puedan hacer que las evaluaciones sean repetibles.

Eso significa fijar las instantáneas de los modelos cuando sea posible, registrar los prompts y la configuración, controlar la aleatoriedad cuando la plataforma lo permita y ejecutar múltiples pruebas para las tareas cuyos resultados varían. El resumen señala específicamente que las instantáneas fijadas, una temperatura baja o de cero cuando esté disponible y las barreras de CI/CD con límites de confianza son salvaguardas útiles.

Un informe práctico debería distinguir al menos tres resultados:

  1. Tasa de aprobación: cuántos casos tuvieron éxito.
  2. Consistencia: con qué frecuencia el mismo caso tiene éxito en ejecuciones repetidas.
  3. Gravedad: si las fallas son estéticas, inconvenientes, dañinas para los datos, relevantes para la seguridad o capaces de provocar una acción externa insegura.

Un sistema que supera 19 de 20 verificaciones de formato de bajo riesgo no es necesariamente mejor que uno que supera 18 de 20 casos, pero nunca cruza un límite de autorización. El estándar de calidad debe ponderar las fallas según sus consecuencias.

La revisión humana debe centrarse en el riesgo, no en cada línea

El propósito de una mejor automatización no es obligar a una persona a releer cada token producido por una IA. Es dirigir la atención humana hacia las decisiones que las pruebas no pueden resolver por completo.

Los revisores deben centrarse en la autenticación y la autorización, la retención de datos, las acciones financieras o contractuales, la privacidad, las migraciones, la recuperación ante errores, los permisos de terceros y los cambios que afectan al propio sistema de evaluación. En el caso de un agente, también deben revisar qué herramientas puede invocar, a qué datos puede acceder cada herramienta y si se requiere aprobación antes de una acción irreversible.

Las diferencias visibles, los flujos de trabajo de aprobación, las conversaciones archivadas y los registros de auditoría —funciones destacadas en la descripción de Slack Code sobre la programación colaborativa con IA— apuntan hacia una expectativa más amplia: la historia de cómo se creó el software será importante. Un revisor debería poder entender la solicitud, inspeccionar el cambio generado, ver la evidencia de las pruebas e identificar quién aprobó el despliegue.

Ese registro no es burocracia por sí misma. Permite distinguir una demostración impresionante de un cambio controlado que otra persona puede mantener.

Qué incluir en un portafolio o una entrevista

Para los candidatos, la demostración más sólida es un sistema pequeño con una historia de calidad deliberadamente visible. Incluye el repositorio, las instrucciones de configuración, notas sobre la arquitectura, comandos de prueba, casos de prueba representativos, limitaciones conocidas y un breve informe de fallas. Muestra uno o dos errores que se hayan detectado y convertido en pruebas de regresión. Explica qué modelo o agente de programación se utilizó sin presentar la herramienta como la autora de las decisiones de ingeniería.

Si la aplicación utiliza un agente, documenta los permisos de las herramientas, el modelo de estado, la política de reintentos, la condición de terminación y los puntos de aprobación humana. Si utiliza recuperación de información, muestra cómo se seleccionan las fuentes y qué ocurre cuando falta evidencia. Si invoca servicios externos, demuestra el comportamiento ante tiempos de espera agotados y solicitudes duplicadas.

No afirmes que existe confiabilidad a partir de una sola grabación exitosa. Una afirmación comprobable sonaría más así: “En 30 ejecuciones registradas de estos 12 escenarios, el sistema cumplió los criterios de aceptación en 28; las dos fallas involucraron una entrada de fecha ambigua y ambas están documentadas”. El número en sí es menos importante que el método, los límites y la honestidad sobre lo que aún no se ha probado.

La nueva definición de rapidez

La IA reduce el costo de producir una primera versión. No elimina el costo de saber si esa versión merece confianza. De hecho, una generación más rápida puede hacer que la evaluación sea más importante, porque pueden acumularse más cambios sin revisar entre un despliegue y otro.

Al profesional de la programación posterior a la era del “vibe coding” se le juzgará por el ciclo: definir el comportamiento, generar o modificar código, probar casos realistas y adversariales, inspeccionar las decisiones de alto riesgo, registrar las fallas y mejorar el sistema sin perder la evidencia. Los benchmarks pueden ayudar a comparar la capacidad. Las prácticas de control de calidad determinan si esa capacidad se convierte en software confiable.

Por lo tanto, el estándar de calidad no es “¿Puedes crear una aplicación con IA?”. Es “¿Puedes demostrar qué hace la aplicación, detectar cuándo deja de hacerlo y diseñar los límites que eviten que una falla se convierta en un incidente?”.