Usar pruebas y descripciones de comportamiento para controlar codigo escrito por IA

Tue, 05 May 2026 14:35:38 +0800

Al escribir codigo con IA, la experiencia mas comun es: al principio todo va rapido, despues se vuelve caotico. Las funciones iniciales se montan muy deprisa, pero cuando el proyecto crece y las modificaciones se acumulan, aparece el patron de arreglar un bug y crear tres mas.

Esto no es solo problema de la IA. Muchas personas tambien programan asi; la diferencia es que la IA escribe mas rapido y los problemas se exponen antes. Para reducir ese descontrol, la clave no es pedir a la IA que “se esfuerce mas”, sino darle limites mas claros: primero definir que resultado cuenta como correcto y luego dejar que escriba la implementacion.

TDD y BDD encajan bien dentro del flujo de programacion con IA. TDD convierte “si esta bien o mal” en pruebas automaticas; BDD convierte “si esto es lo que quiero” en descripciones de comportamiento comprensibles por personas. Combinados, hacen que la IA adivine menos, improvise menos y sea mas facil de revisar.

Que problema resuelve TDD

TDD significa Test Driven Development, desarrollo guiado por pruebas. Su secuencia basica es:

Escribir primero las pruebas.
Ejecutarlas y confirmar que ahora fallan.
Escribir despues el codigo funcional.
Ajustar la implementacion hasta que las pruebas pasen.

Esto es lo contrario de lo que mucha gente acostumbra. Al escribir una funcion de ordenacion, la intuicion suele ser escribir primero la funcion y luego probar algunos numeros a mano. TDD pide escribir antes las expectativas como pruebas: por ejemplo, que con [3, 1, 2] se obtenga [1, 2, 3], que un array vacio devuelva un array vacio, y que una entrada con numeros repetidos tambien produzca un resultado correcto.

El sentido de hacerlo asi es que, antes de empezar a desarrollar, el resultado correcto ya esta definido. Mas adelante, quien cambie el codigo solo necesita volver a ejecutar las pruebas para saber si rompio un comportamiento acordado.

Por que antes costaba mantener TDD

TDD suena muy bien, pero en proyectos reales no es facil sostenerlo durante mucho tiempo.

Primero, va contra la intuicion. Frente a un archivo vacio, muchas personas prefieren escribir la funcion antes que las pruebas. Cuando los requisitos todavia no estan claros, escribir casos de prueba tambien cuesta.

Segundo, los requisitos cambian rapido. Una docena de pruebas escritas hoy con mucho cuidado pueden necesitar reescritura masiva si manana cambia el producto. A corto plazo, parece ralentizar el desarrollo.

Tercero, las pruebas tambien tienen coste. El codigo de pruebas no aparece de la nada: antes lo escribia, mantenia y justificaba el programador. En equipos que solo miran la velocidad de entrega a corto plazo, esto se suele recortar.

Pero la IA cambia esta estructura de costes. Convertir requisitos en pruebas es precisamente una tarea en la que la IA es fuerte. Pedirle que implemente segun pruebas tambien es mucho mas fiable que dejarla improvisar a partir de una descripcion vaga.

Como usar TDD al programar con IA

Al pedir una funcion a la IA, puedes cambiar el prompt de “ayudame a implementar esto” a este orden:

Pedir a la IA que primero enumere casos de prueba segun el requisito.
Exigir que cada caso tenga una explicacion en chino o en el idioma de trabajo del equipo.
Revisar primero si los casos de prueba representan la necesidad real.
Despues de confirmar las pruebas, pedir a la IA que escriba la implementacion.
Pedir a la IA que ejecute las pruebas y corrija segun los fallos.

En ese momento, la persona revisa sobre todo si las pruebas expresan bien el requisito, no una gran implementacion. Los casos de prueba suelen estar mas cerca de “cual es la entrada, cual deberia ser la salida y como se manejan los bordes”, por lo que son mas faciles de leer que la logica interna.

Por ejemplo, puedes pedirlo asi:

1
2
3

Primero no implementes la funcion.
Segun el requisito siguiente, escribe casos de prueba. Cada caso debe incluir un comentario en chino que explique la regla de negocio cubierta.
Cuando confirme las pruebas, implementa el codigo segun ellas.

Este flujo reduce dos problemas comunes: que la IA se desvie del tema y que cambios posteriores rompan funciones antiguas.

TDD no basta

TDD por si solo todavia deja dos huecos.

El primero: que todas las pruebas pasen no significa que el producto cumpla la expectativa. Las pruebas solo demuestran que el codigo cumple las reglas que se escribieron en ellas. Si las pruebas no expresan bien la necesidad del usuario, el codigo puede seguir “haciendo mal lo correcto”.

El segundo: el codigo de pruebas sigue sin ser amable para usuarios no tecnicos. Incluso con comentarios, muchas personas no quieren leer montones de tests unitarios. Cuanto mas orientado a experiencia de producto sea el requisito, mas dificil es confirmar desde pruebas si “esto es lo que queria”.

Ahi entra BDD.

Que problema resuelve BDD

BDD significa Behavior Driven Development, desarrollo guiado por comportamiento. No se centra en como esta escrito el codigo por dentro, sino en que comportamiento debe mostrar el sistema en un escenario determinado.

La forma habitual de describir BDD es Given / When / Then:

Given: dado cierto estado inicial.
When: cuando el usuario o el sistema realiza una accion.
Then: entonces debe obtenerse cierto resultado.

Por ejemplo, un personaje de juego con robo de vida puede describirse asi:

Given hay un vampiro en el tablero con 1 punto de vida restante, 2 de ataque y 5 de vida maxima
And hay una unidad enemiga adyacente con 10 puntos de vida restantes
When el vampiro ataca a esa unidad enemiga
Then la unidad enemiga queda con 8 puntos de vida
And el vampiro se cura hasta 3 puntos de vida

Esto no es codigo, pero es mucho mas preciso que “se cura al atacar al enemigo”. Define estado inicial, accion y resultado; tambien expone preguntas posteriores: si el enemigo solo tenia 1 punto de vida, ¿el vampiro se cura por el dano causado o por su ataque? Si el vampiro ya esta al maximo, ¿que ocurre con la curacion sobrante?

Cuanto antes aparezcan estas preguntas, menos tendra que adivinar la IA despues.

Por que BDD encaja tan bien con IA

Antes, impulsar BDD tambien tenia coste. Requeria que producto, desarrollo y QA hablaran con la misma descripcion de comportamiento, y muchos equipos no tienen ese habito de colaboracion.

En la era de la IA, el coste de BDD baja. Solo necesitas escribir primero una necesidad aproximada, por ejemplo:

`1`	`Despues de atacar a un enemigo, el vampiro recupera una cantidad de vida igual al dano causado.`

Luego pides a la IA que genere escenarios Given / When / Then. Una buena IA agregara casos limite y preguntara por reglas ambiguas. Tu trabajo sera confirmar esas descripciones de comportamiento, no leer directamente la implementacion.

Una vez confirmadas las descripciones, pide a la IA que las convierta en pruebas y finalmente que implemente segun esas pruebas. El camino se vuelve mucho mas claro.

Un flujo mas estable para programar con IA

En la practica, puedes encadenar BDD y TDD:

Escribe el requisito en lenguaje natural.
Pide a la IA que lo convierta en escenarios BDD.
Confirma si Given / When / Then encajan con la expectativa.
Pide a la IA que convierta esos escenarios en pruebas automaticas.
Revisa rapidamente la cobertura de las pruebas.
Pide a la IA que implemente la funcion.
Ejecuta las pruebas; si fallan, pide a la IA que corrija segun los errores.
Haz una aceptacion manual y una revision de codigo final.

La clave esta en el orden. No empieces pidiendo una implementacion completa. Primero haz que la IA convierta el requisito en comportamiento verificable y despues en pruebas ejecutables. Asi su espacio de improvisacion se reduce mucho.

Puedes usar directamente un prompt como este:

Procesa este requisito siguiendo un flujo BDD + TDD.

Paso 1: primero organiza el requisito en escenarios Given / When / Then, sin escribir codigo.
Paso 2: enumera las reglas ambiguas que detectes y preguntame para confirmarlas.
Paso 3: cuando los escenarios esten confirmados, conviertelos en casos de prueba.
Paso 4: cuando las pruebas esten confirmadas, implementa la funcion.
Paso 5: ejecuta las pruebas y corrige segun los fallos hasta que pasen.

Este tipo de prompt no es complicado, pero cambia claramente la forma de trabajar de la IA. Primero acota el requisito y luego entra en implementacion, en vez de escribir desde el principio mucho codigo que parece completo pero resulta dificil de verificar.

Escenarios donde conviene usarlo primero

BDD + TDD no tiene que aplicarse a todo. Para scripts de una sola vez, procesamiento temporal de datos o pequenos ajustes de estilo, el flujo completo puede ser excesivo.

Encaja mejor en estos casos:

Hay muchas reglas de negocio y se entienden mal con facilidad.
Hay muchos bordes y se seguira modificando.
Funciones de logica densa como juegos, facturacion, permisos, maquinas de estado o validacion de formularios.
Hace falta confirmar requisitos entre varias personas.
El codigo se mantendra a largo plazo, no se genera una sola vez.
El proyecto ya muestra el problema de que “cuanto mas corrige la IA, mas se enreda”.

Si solo quieres cambiar el texto de un boton, no hace falta todo el proceso. Pero si vas a crear un sistema de habilidades de personajes, flujo de estados de pedidos, logica de permisos o reglas de puntos, escribir primero comportamientos y pruebas suele compensar.

Que tener en cuenta

Primero, mas pruebas no siempre es mejor. Las pruebas deben cubrir reglas clave y bordes de alto riesgo, no bloquear cada detalle de implementacion. Si no, cualquier cambio menor de requisito convierte las pruebas en una carga de mantenimiento.

Segundo, los escenarios BDD deben ser concretos. No escribas frases como “el sistema deberia funcionar normalmente” o “la experiencia deberia ser fluida”, porque no son verificables. Hay que especificar el estado dado, la accion y el resultado esperado.

Tercero, las personas aun deben revisar. La IA puede generar pruebas y escenarios de comportamiento, pero no sabe cual es tu verdadero criterio de producto. Las reglas limite, en especial, deben ser confirmadas por una persona.

Cuarto, despues de pasar las pruebas hay que ejecutar la funcion real. Las pruebas automaticas ayudan con la logica, pero la experiencia de interfaz, rendimiento, interaccion y sensacion de usuario aun requieren aceptacion manual.

Resumen

La IA escribe codigo rapido, pero rapido no significa estable. Cuanto mas complejo es el requisito, menos conviene depender de un simple “ayudame a implementarlo”. Es mejor dividir primero la necesidad en comportamientos verificables, convertirlos en pruebas ejecutables y finalmente dejar que la IA implemente segun esas pruebas.

TDD le dice a la IA que resultado cuenta como correcto. BDD ayuda a las personas a confirmar si esa funcion es realmente la que quieren. Juntos no agregan ceremonia por la ceremonia, sino que reducen el espacio de adivinacion de la IA y convierten “escribir rapido” en “modificar de forma estable”.

TDD on KnightLi Blog