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

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

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. Quienes 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 una prueba, no una puntuación en una tabla 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 utiliza incidencias reales de GitHub y copias instantáneas de repositorios, por lo que resulta relevante para el trabajo de mantenimiento. Terminal-Bench prueba la interacción con la línea de comandos. Otros benchmarks enumerados, incluidos SlopCodeBench y ProgramBench, se centran 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 deberían ser cautelosos a la hora de tratar cualquier puntuación individual como una prueba de preparación para producción. Un modelo que resuelve incidencias 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 demostración del camino feliz y, aun así, gestionar mal los reintentos o los pagos duplicados.

Por tanto, un portafolio creíble o una revisión interna 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 los usuarios, 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 creado con IA

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

  • Pruebas de aceptación: verifican el comportamiento visible para el usuario en los flujos de trabajo más importantes, incluidos los resultados satisfactorios y no satisfactorios.
  • 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 funcionan conjuntamente como se espera.
  • Pruebas negativas: envían entradas ausentes, malformadas, demasiado grandes, duplicadas y no autorizadas. El código generado por IA suele parecer más sólido en el camino mostrado en la indicación, por lo que los caminos no solicitados son importantes.
  • Pruebas de regresión: convierten cada defecto descubierto en una prueba permanente. Una demostración en verde después de una corrección no basta si el mismo fallo puede volver a aparecer en el siguiente cambio generado.
  • Controles de seguridad: prueban el control de acceso, la gestión de secretos, las defensas contra inyecciones, las vulnerabilidades de dependencias y si el contenido no confiable puede influir en las llamadas a herramientas o en acciones privilegiadas.
  • Controles operativos: verifican los tiempos de espera, los reintentos, la idempotencia, el registro, las alertas y el comportamiento seguro cuando una dependencia no está disponible.

Esto se aproxima a la mentalidad de ingeniería de control de calidad descrita en el relato de Stack Overflow sobre un ciclo de vida del desarrollo de software agéntico. El cambio importante es cultural: el control de 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 ordinarias de la aplicación son necesarias, pero insuficientes. El sistema puede fallar porque el modelo entendió 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 indicaciones, salida estructurada, no terminación, fundamentación de la recuperación y rehidratación del estado. Son propiedades de ingeniería que se pueden probar.

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

Los sistemas de larga duración y multiagente necesitan registros de fallos especialmente claros. Los investigadores trabajan en la atribución automatizada de fallos porque puede resultar difícil identificar qué agente causó un fallo y en qué punto 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 esas pruebas, una prueba en rojo te indica que algo falló, pero no por dónde empezar a solucionarlo.

La reproducibilidad se convertirá en una ventaja profesional

El código generado por IA es variable. Una repetició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 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 las indicaciones y la configuración, controlar la aleatoriedad cuando la plataforma lo permita y ejecutar varios ensayos para las tareas cuyos resultados varíen. El resumen señala específicamente las instantáneas fijadas, una temperatura baja o cero cuando esté disponible y las barreras de CI/CD con límites de confianza como salvaguardas útiles.

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

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

Un sistema que supera 19 de 20 comprobaciones 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 umbral de calidad debe ponderar los fallos 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 utilizar, 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 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: importará el historial de cómo se creó el software. Un revisor debería poder entender la solicitud, inspeccionar el cambio generado, ver las pruebas realizadas 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 en 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 fallos. 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 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 llama a servicios externos, demuestra el comportamiento ante tiempos de espera agotados y solicitudes duplicadas.

No afirmes que existe fiabilidad basándote en una sola grabación exitosa. Una afirmación comprobable sonaría más bien así: «En 30 ejecuciones registradas de estos 12 escenarios, el sistema cumplió los criterios de aceptación en 28; los dos fallos implicaron una entrada de fecha ambigua y ambos están documentados». El número en sí es menos importante que el método, los límites y la honestidad sobre lo que sigue sin probarse.

La nueva definición de rapidez

La IA reduce el coste de producir una primera versión. No elimina el coste 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 despliegues.

El profesional de la era posterior al «vibe coding» será evaluado por el ciclo: definir el comportamiento, generar o modificar código, probar casos realistas y adversarios, inspeccionar las decisiones de alto riesgo, registrar los fallos 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 fiable.

Por tanto, el umbral 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 impidan que un fallo se convierta en un incidente?»