El bucle escribió el código; los tests lo hicieron fiable
· Javier Miralles · 7 min
Una noche dejé un bucle escribiendo software y me fui a dormir
La noche del 12 al 13 de julio programé un proceso para que se despertara solo a las 02:30 y se pusiera a escribir código. No a "ayudarme": a hacerlo entero, sin nadie mirando. A las 03:18 había terminado. Doce vueltas, unos cuatro minutos cada una, catorce módulos de cálculo nuevos y 243 pruebas en verde. Cuando me levanté, el trabajo estaba hecho y me esperaba un correo con el parte.
Suena a titular de moda: "la IA ya escribe el software sola". Y sí, hay una parte de eso. Pero el titular de verdad, el que me hizo pensar durante el café, es otro: esa noche el bucle cazó dos errores reales en las fórmulas. Errores que estaban en el código que yo mismo había escrito antes, a mano. Errores que un humano con prisa un viernes a las siete de la tarde deja pasar sin enterarse.
Así que este artículo no va de que la IA escriba código. Va de por qué me fío de ese código más que del que escribí yo con prisa. Y la respuesta no es "porque lo hizo la IA". Es lo contrario.
"Ya no se promptea, se loopea" — pero eso es solo la mitad
El patrón que probé se llama Ralph, y lo popularizó Geoffrey Huntley. La idea, resumida en una frase que corre estos meses, es: "ya no se promptea, se loopea". En vez de pedirle una cosa a un modelo y recoger la respuesta, montas un bucle: el modelo lee un objetivo, hace un trozo, guarda su avance en ficheros y en git, y vuelve a empezar. Otra vez. Y otra. Hasta que una condición de parada dice basta.
Es elegante y funciona. Pero si te quedas ahí, has construido una máquina de escribir código rápido. Rápido no es lo mismo que bien. Un bucle sin frenos es un becario con mucho café y cero criterio: produce a toda velocidad y con la misma velocidad mete la pata.
Lo que hace que un bucle sirva para algo serio no es el bucle. Son los frenos que le pones debajo. Le puse tres, y son la única razón por la que aquella noche salió bien:
| El freno | Qué le obliga a hacer | Qué error evita |
|---|---|---|
| Los tests son la verdad | No puede dar una fórmula por buena hasta que pasa una prueba con un caso oficial real | Que "parezca" correcto y no lo sea |
| Verifica antes de escribir | Antes de meter una cifra, tiene que ir a la fuente (BOE, AEAT) y confirmarla | Inventarse un número plausible |
| Prohibido inventar | Si no encuentra la fuente, se para y lo dice; no rellena huecos | Tapar un agujero con una suposición |
Fíjate en que ninguno de los tres tiene que ver con la IA. Son disciplina de oficio de toda la vida. La IA solo los ejecuta sin cansarse y sin excusas.
Los dos errores que estaban ahí y nadie veía
Aquí es donde la teoría se vuelve concreta, que es lo único que me interesa.
El primer error estaba en el cálculo de una nómina. La reducción por rendimientos del trabajo del IRPF (el artículo 20 de la ley, para quien quiera comprobarlo) tiene tres tramos. Mi código a mano modelaba solo dos: se había dejado el coeficiente del medio. El resultado: en sueldos brutos de entre 18.900 y 21.120 euros, la calculadora sobreestimaba el IRPF. No por un céntimo, por un tramo entero mal. Llevaba ahí desde que lo escribí.
El segundo estaba en el propio IRPF. El código restaba el mínimo personal de la base antes de aplicar la escala de tramos. Suena razonable. Está mal. La ley (artículo 63) te obliga a aplicar la escala a la base por un lado y al mínimo por otro, y luego restar los dos resultados. La diferencia entre las dos formas de calcular no es de matiz: son euros distintos en la declaración de una persona real.
El bucle los encontró porque, antes de tocar cada calculadora, tenía la obligación de ir a la fuente oficial, entender la fórmula legal y escribir una prueba con un caso resuelto. Cuando la prueba no cuadraba con mi código viejo, no "arreglaba la prueba para que pasara": arreglaba el código. Un humano con prisa habría hecho justo lo contrario, y lo digo porque ese humano con prisa había sido yo unos meses antes.
Lo más valioso fue cuando se negó a trabajar
Hubo un momento en las primeras pruebas del patrón que me convenció más que ningún test en verde. En un intento anterior, el bucle se quedó sin acceso a internet y sin permiso para guardar en git (un problema de configuración, culpa mía). Un sistema mal diseñado, en esa situación, habría seguido adelante: se habría inventado las cifras que no podía verificar y habría entregado algo que parece completo. El terror de cualquiera que compra software.
El nuestro hizo lo contrario. Se paró. Escribió en su bitácora que no podía verificar nada, explicó por qué, propuso cómo arreglarlo y no tocó una sola fórmula. Prefirió no entregar antes que entregar algo sin comprobar.
Eso no es suerte. Es la tercera regla — "prohibido inventar" — haciendo su trabajo. Y es exactamente lo que quiero de cualquiera, humano o máquina, que construya algo de lo que luego respondo yo.
Lo que aún no está resuelto
No quiero vender esto como magia, porque no lo es. El bucle es tan bueno como los frenos que le pones, y ponerlos bien cuesta. Si tus pruebas son flojas, el bucle produce basura rápido y con mucha confianza. Escribir un buen caso de prueba con la fuente legal delante sigue siendo trabajo humano, y del difícil.
Tampoco deploya nada solo, a propósito. Aquella noche dejó el código escrito y probado, pero publicarlo en producción fue una decisión que tomé yo, despierto, al día siguiente. Hay una línea que no le cedo a ninguna máquina, y esa es una.
Y hay un detalle incómodo: durante unos días, la web pública seguía sirviendo las fórmulas viejas, con el error, mientras los arreglos esperaban a que alguien pulsara el botón de publicar. El bucle caza el fallo; cerrarlo del todo sigue dependiendo de que un humano remate. Lo cuento porque es verdad, no porque quede bien.
Lo que me llevo, y lo que te llevas tú si compras software
La lección para nosotros es fácil: el bucle se queda. Pero la que de verdad importa es para quien está al otro lado, el que paga por un software que no escribió y no puede leer.
La pregunta que casi todo el mundo hace es "¿esto lo hizo un humano o una IA?". Es la pregunta equivocada. Da igual quién teclee. La pregunta buena es: ¿qué hay debajo que impide que esté mal? ¿Hay pruebas con casos reales? ¿Alguien verificó las cifras contra la fuente, o se dieron por buenas porque parecían razonables? ¿El sistema se para cuando no sabe, o rellena el hueco y sigue?
Un becario con café y sin frenos y un bucle con café y sin frenos producen el mismo software: rápido y mal. La velocidad de la IA no cambia esa ecuación. Solo la hace más rápida en las dos direcciones. Construir software dejó de ser el problema hace tiempo. Construirlo bien sigue siéndolo.
Es la misma frontera de la que hablé en otro artículo sobre por qué una app que funciona en la demo se cae en producción: "funciona" y "está bien construido" son dos cosas distintas, y la distancia entre ellas es justo donde vive el trabajo de verdad.
Si estás a punto de encargar o comprar software y quieres saber qué le preguntaría yo a quien te lo vende antes de firmar, escríbeme a contact@easybyte.es y te lo cuento. Sin formulario y sin compromiso: una respuesta de alguien que ha estado a los dos lados.
— Javier
EasyByte Hub S. Coop. Mad. — Madrid, julio de 2026