Actualidad
Viernes Pizza: cuatro formas de llevar la IA al trabajo real
Producir por diez es posible. Pero el multiplicador no vive en el prompt. Vive en lo que la IA no te da y tienes que poner tú, con criterio: requisitos claros y verificación determinista.
Vibe coding es programar describiendo en un chat lo que quieres y dejando que el modelo escriba el código. Todos los que llevamos unos meses haciéndolo hemos vivido la misma escena. Pides un cambio. La IA lo entrega con seguridad absoluta. Lo pruebas y no funciona. Se lo dices. Y llega la frase:
«Tienes razón, me equivoqué.»
Y otra versión. Y otra vez el mismo baile. Media tarde después tienes tres archivos tocados, dos regresiones que aún no sabes que existen y la sensación incómoda de haber ido muy rápido hacia ninguna parte.
Lo difícil de asumir es que esa tarde perdida no contradice el x10. Lo demuestra.
Hace un año esto era un meme: código a golpe de chat para prototipos de fin de semana. Lo que ha cambiado no es solo que los modelos escriban mejor. Es que ahora leen el repositorio entero, ejecutan herramientas, prueban y corrigen solos, y el coste de una línea de código se ha hundido. Generar ha dejado de ser el trabajo.
La capacidad de generar código ya se ha multiplicado. Eso está hecho, no hay discusión y no tiene vuelta atrás. Lo que no se ha multiplicado por sí solo es la capacidad de saber si ese código está bien. Y el x10 real, el que llega al cliente y no el que sale del editor, se mide en la segunda cifra, no en la primera.
Te adelanto el final: ese multiplicador no se captura escribiendo mejores prompts. Se captura industrializando la verificación.
Un modelo de lenguaje produce la continuación más plausible. En código, plausible significa sintaxis correcta, nombres coherentes, estructura reconocible, patrón familiar. Todo eso puede cumplirse al cien por cien y el código puede seguir estando mal.
Cuando le dices «esto no funciona», el modelo no ha descubierto nada nuevo sobre tu sistema. Ha recibido una señal, tu descontento, y genera la continuación plausible para esa señal: disculparse y reintentar. Por eso el bucle puede durar indefinidamente. Estás usando tu criterio humano, leído a través de un chat, como único oráculo de corrección. Es caro, es lento y se degrada a las siete de la tarde.
Lo único que distingue de forma determinista «plausible» de «correcto» en software es la ejecución. Un test que pasa o falla no tiene opinión, no se disculpa y no cambia de criterio según cómo se lo preguntes.
Con una matización que conviene hacer pronto: un test en verde no demuestra que el código sea correcto. Demuestra que los comportamientos que has decidido proteger siguen cumpliéndose. Es una garantía parcial, pero es la única que no depende de la opinión de nadie. Y mantenerla así obliga a tratar un test intermitente como un test roto, no como ruido.
El ciclo de vida del software sigue teniendo las mismas fases. Lo que ha cambiado, y de forma brutal, es cuánto pesa cada una.
| Fase | Antes | Con IA en el bucle |
|---|---|---|
| Requisitos y diseño | Documento ligero, a menudo implícito | Crítico: el requisito es el prompt |
| Escribir el código | Más de la mitad del esfuerzo | Fracción marginal |
| Verificación (test y revisión) | Lo primero que se recorta | El centro de gravedad del proceso |
| Despliegue y operación | Pipeline establecido | Crítico por frecuencia: obliga a rollback barato y observabilidad real |
El esfuerzo no ha desaparecido: se ha desplazado a los dos extremos. Hacia arriba, a definir bien qué quieres, porque toda ambigüedad que dejes la rellenará la IA por su cuenta con una suposición razonable y equivocada. Y hacia abajo, a comprobar que lo generado hace lo que esperas.
Aquí es donde cae la mayoría de equipos: adoptan la IA en la fase que se ha vuelto barata y dejan intacto el proceso de la fase que se ha vuelto cara. Se genera diez veces más código y se revisa igual que siempre, un humano leyendo diffs. Si generar es diez veces más barato y verificar sigue siendo manual, no has multiplicado por diez tu capacidad: has movido el atasco y lo has hecho más grande.
Y el problema no se queda en un simple atasco. A partir de cierto volumen empieza a acumularse código que nadie ha comprobado de verdad, y ese código genera incidencias, retrabajo y desconfianza. Llega un punto en el que cada funcionalidad nueva cuesta más que la anterior, porque hay que sostener todo lo que se aceptó sin verificar. Más código, menos confianza. Es la deuda técnica de siempre, solo que ahora se genera diez veces más deprisa.
La solución no es un proceso nuevo. Es el de siempre, con el testing elevado a elemento determinista: lo único que dice, sin conversaciones ni suposiciones de por medio, si el código hace lo que tiene que hacer.
Fíjate primero en lo que no cambia: el prompt es el mismo, el código generado es el mismo, y el «parece que funciona» sigue estando ahí porque es inevitable. Lo que cambia es que ese «parece» ha dejado de decidir. Y ojo con dónde nace el test: no se escribe leyendo el código recién generado, se deriva del criterio de aceptación. Lo que se interpone antes de entregar es su ejecución.
Y fíjate en la parte incómoda: los dos ciclos entregan. Mirando una sola iteración, el vibe coding sin criterio no es más lento ni produce menos: produce igual y entrega igual. La diferencia no está en lo que sale hoy. Está en quién descubre el fallo, y en lo que eso te cobra a los seis meses.
En el primer ciclo lo descubre el cliente. Tu suite de tests es el cliente, y es la más cara que existe: el coste ya no es técnico, es de confianza. En el segundo lo descubre un test: en segundos en tu máquina y en minutos en la pipeline, semanas antes de que lo note nadie fuera del equipo. Y cuando falla, no vuelve con una disculpa. Vuelve con una causa concreta y reproducible: un test en rojo, una línea, un valor esperado frente al que ha salido. Eso sí lo entiende la IA, y con eso se corrige sola.
Con una condición que no es menor: el test es del equipo, no del agente. Si la IA puede tocar el test para ponerlo en verde (relajar la comprobación, simular justo lo que fallaba, añadir un caso especial para el dato de la prueba), has vuelto al punto de partida con más ceremonia. El test cambia cuando cambia el requisito, y ese cambio lo revisa una persona.
Y algo se escapará igual. La diferencia es que lo que se escapa entra en la suite y no vuelve a escaparse.
Es la misma IA en los dos casos. Lo único que cambia es quién hace de juez.
Cinco reglas. No son sofisticadas, y esa es exactamente la gracia.
El efecto compuesto de aplicarlas:
| Efecto | Sin verificación determinista | Con verificación determinista |
|---|---|---|
| Generar código | x10 | x10 |
| Saber si funciona | x1: tú probando a mano | x10: suite automática |
| Detectar regresiones | En el cliente | En el commit |
| Coste de iterar | Crece con el proyecto | Estable |
| Multiplicador real | x1,5 y bajando | x10 y sostenible |
Órdenes de magnitud, no mediciones: la tabla ilustra la dirección del efecto, no un estudio.
Al agente le delegamos lo que es barato equivocarse y caro hacer a mano: escribir el código, proponer variantes, corregir cuando un test se pone en rojo, repetir la vuelta las veces que haga falta. Lo que protegemos es lo que no se revierte con un commit.
Un modelo optimiza el archivo que tiene delante, no los próximos tres años. Por eso las fronteras del sistema (los contratos de API, los esquemas de datos, las migraciones) no se le entregan: se le dan como condición. Son el contrato dentro del cual trabaja y que no puede renegociar en una iteración. Cuando el agente propone cambiar una frontera, eso ya no es una tarea: es una decisión, y la toma una persona.
Revisar código generado no es leer diez veces más líneas. Es revisar lo que importa: que el test se derive del requisito y no del código, que el cambio sea pequeño, que no toque una frontera y que el verde sea un verde honesto. Si el agente ha tocado el test para ponerlo en verde, la revisión tiene que verlo. Es un oficio distinto del de leer diffs, y hay que aprenderlo.
Donde el humano no sale del bucle
La IA multiplica por diez escribir código. Lo que no multiplica es la capacidad de saber si ese código está bien, y ahí se decide si el x10 llega al cliente o se queda en el editor. Esa parte no la compra un modelo mejor: se construye.
Haz eso y «tienes razón, me equivoqué» deja de ser el bucle en el que se te va la tarde. Simplemente deja de importar, porque quien decide ya no es la conversación.
Y si eres el cliente de un equipo que programa con IA, la velocidad que te prometen no es un argumento de venta. Es una responsabilidad. La pregunta no es qué modelo usan. Es quién hace de juez, y se concreta en cuatro preguntas: qué tests protegen lo que te entregan, de dónde salen esos tests (del requisito o del código), qué bloquea una entrega cuando algo está en rojo, y quién revisa el cambio cuando el agente toca un test.
Daniel responde en vídeo a las diez preguntas de este artículo: cómo empieza una tarea real, qué se le deja al modelo y qué no, qué pasa cuando el agente toca el test para ponerlo en verde, y qué debería preguntar cualquier empresa a su proveedor sobre cómo verifica el código generado con IA.
Escrito por
Daniel Pereira
Arquitecto de sistemas en Origen
Producir por diez es posible. Pero el multiplicador no vive en el prompt. Vive en lo que la IA no te da y tienes que poner tú, con criterio: requisitos claros y verificación determinista.
Vibe coding es programar describiendo en un chat lo que quieres y dejando que el modelo escriba el código. Todos los que llevamos unos meses haciéndolo hemos vivido la misma escena. Pides un cambio. La IA lo entrega con seguridad absoluta. Lo pruebas y no funciona. Se lo dices. Y llega la frase:
«Tienes razón, me equivoqué.»
Y otra versión. Y otra vez el mismo baile. Media tarde después tienes tres archivos tocados, dos regresiones que aún no sabes que existen y la sensación incómoda de haber ido muy rápido hacia ninguna parte.
Lo difícil de asumir es que esa tarde perdida no contradice el x10. Lo demuestra.
Hace un año esto era un meme: código a golpe de chat para prototipos de fin de semana. Lo que ha cambiado no es solo que los modelos escriban mejor. Es que ahora leen el repositorio entero, ejecutan herramientas, prueban y corrigen solos, y el coste de una línea de código se ha hundido. Generar ha dejado de ser el trabajo.
La capacidad de generar código ya se ha multiplicado. Eso está hecho, no hay discusión y no tiene vuelta atrás. Lo que no se ha multiplicado por sí solo es la capacidad de saber si ese código está bien. Y el x10 real, el que llega al cliente y no el que sale del editor, se mide en la segunda cifra, no en la primera.
Te adelanto el final: ese multiplicador no se captura escribiendo mejores prompts. Se captura industrializando la verificación.
Un modelo de lenguaje produce la continuación más plausible. En código, plausible significa sintaxis correcta, nombres coherentes, estructura reconocible, patrón familiar. Todo eso puede cumplirse al cien por cien y el código puede seguir estando mal.
Cuando le dices «esto no funciona», el modelo no ha descubierto nada nuevo sobre tu sistema. Ha recibido una señal, tu descontento, y genera la continuación plausible para esa señal: disculparse y reintentar. Por eso el bucle puede durar indefinidamente. Estás usando tu criterio humano, leído a través de un chat, como único oráculo de corrección. Es caro, es lento y se degrada a las siete de la tarde.
Lo único que distingue de forma determinista «plausible» de «correcto» en software es la ejecución. Un test que pasa o falla no tiene opinión, no se disculpa y no cambia de criterio según cómo se lo preguntes.
Con una matización que conviene hacer pronto: un test en verde no demuestra que el código sea correcto. Demuestra que los comportamientos que has decidido proteger siguen cumpliéndose. Es una garantía parcial, pero es la única que no depende de la opinión de nadie. Y mantenerla así obliga a tratar un test intermitente como un test roto, no como ruido.
El ciclo de vida del software sigue teniendo las mismas fases. Lo que ha cambiado, y de forma brutal, es cuánto pesa cada una.
| Fase | Antes | Con IA en el bucle |
|---|---|---|
| Requisitos y diseño | Documento ligero, a menudo implícito | Crítico: el requisito es el prompt |
| Escribir el código | Más de la mitad del esfuerzo | Fracción marginal |
| Verificación (test y revisión) | Lo primero que se recorta | El centro de gravedad del proceso |
| Despliegue y operación | Pipeline establecido | Crítico por frecuencia: obliga a rollback barato y observabilidad real |
El esfuerzo no ha desaparecido: se ha desplazado a los dos extremos. Hacia arriba, a definir bien qué quieres, porque toda ambigüedad que dejes la rellenará la IA por su cuenta con una suposición razonable y equivocada. Y hacia abajo, a comprobar que lo generado hace lo que esperas.
Aquí es donde cae la mayoría de equipos: adoptan la IA en la fase que se ha vuelto barata y dejan intacto el proceso de la fase que se ha vuelto cara. Se genera diez veces más código y se revisa igual que siempre, un humano leyendo diffs. Si generar es diez veces más barato y verificar sigue siendo manual, no has multiplicado por diez tu capacidad: has movido el atasco y lo has hecho más grande.
Y el problema no se queda en un simple atasco. A partir de cierto volumen empieza a acumularse código que nadie ha comprobado de verdad, y ese código genera incidencias, retrabajo y desconfianza. Llega un punto en el que cada funcionalidad nueva cuesta más que la anterior, porque hay que sostener todo lo que se aceptó sin verificar. Más código, menos confianza. Es la deuda técnica de siempre, solo que ahora se genera diez veces más deprisa.
La solución no es un proceso nuevo. Es el de siempre, con el testing elevado a elemento determinista: lo único que dice, sin conversaciones ni suposiciones de por medio, si el código hace lo que tiene que hacer.
Fíjate primero en lo que no cambia: el prompt es el mismo, el código generado es el mismo, y el «parece que funciona» sigue estando ahí porque es inevitable. Lo que cambia es que ese «parece» ha dejado de decidir. Y ojo con dónde nace el test: no se escribe leyendo el código recién generado, se deriva del criterio de aceptación. Lo que se interpone antes de entregar es su ejecución.
Y fíjate en la parte incómoda: los dos ciclos entregan. Mirando una sola iteración, el vibe coding sin criterio no es más lento ni produce menos: produce igual y entrega igual. La diferencia no está en lo que sale hoy. Está en quién descubre el fallo, y en lo que eso te cobra a los seis meses.
En el primer ciclo lo descubre el cliente. Tu suite de tests es el cliente, y es la más cara que existe: el coste ya no es técnico, es de confianza. En el segundo lo descubre un test: en segundos en tu máquina y en minutos en la pipeline, semanas antes de que lo note nadie fuera del equipo. Y cuando falla, no vuelve con una disculpa. Vuelve con una causa concreta y reproducible: un test en rojo, una línea, un valor esperado frente al que ha salido. Eso sí lo entiende la IA, y con eso se corrige sola.
Con una condición que no es menor: el test es del equipo, no del agente. Si la IA puede tocar el test para ponerlo en verde (relajar la comprobación, simular justo lo que fallaba, añadir un caso especial para el dato de la prueba), has vuelto al punto de partida con más ceremonia. El test cambia cuando cambia el requisito, y ese cambio lo revisa una persona.
Y algo se escapará igual. La diferencia es que lo que se escapa entra en la suite y no vuelve a escaparse.
Es la misma IA en los dos casos. Lo único que cambia es quién hace de juez.
Cinco reglas. No son sofisticadas, y esa es exactamente la gracia.
El efecto compuesto de aplicarlas:
| Efecto | Sin verificación determinista | Con verificación determinista |
|---|---|---|
| Generar código | x10 | x10 |
| Saber si funciona | x1: tú probando a mano | x10: suite automática |
| Detectar regresiones | En el cliente | En el commit |
| Coste de iterar | Crece con el proyecto | Estable |
| Multiplicador real | x1,5 y bajando | x10 y sostenible |
Órdenes de magnitud, no mediciones: la tabla ilustra la dirección del efecto, no un estudio.
Al agente le delegamos lo que es barato equivocarse y caro hacer a mano: escribir el código, proponer variantes, corregir cuando un test se pone en rojo, repetir la vuelta las veces que haga falta. Lo que protegemos es lo que no se revierte con un commit.
Un modelo optimiza el archivo que tiene delante, no los próximos tres años. Por eso las fronteras del sistema (los contratos de API, los esquemas de datos, las migraciones) no se le entregan: se le dan como condición. Son el contrato dentro del cual trabaja y que no puede renegociar en una iteración. Cuando el agente propone cambiar una frontera, eso ya no es una tarea: es una decisión, y la toma una persona.
Revisar código generado no es leer diez veces más líneas. Es revisar lo que importa: que el test se derive del requisito y no del código, que el cambio sea pequeño, que no toque una frontera y que el verde sea un verde honesto. Si el agente ha tocado el test para ponerlo en verde, la revisión tiene que verlo. Es un oficio distinto del de leer diffs, y hay que aprenderlo.
Donde el humano no sale del bucle
La IA multiplica por diez escribir código. Lo que no multiplica es la capacidad de saber si ese código está bien, y ahí se decide si el x10 llega al cliente o se queda en el editor. Esa parte no la compra un modelo mejor: se construye.
Haz eso y «tienes razón, me equivoqué» deja de ser el bucle en el que se te va la tarde. Simplemente deja de importar, porque quien decide ya no es la conversación.
Y si eres el cliente de un equipo que programa con IA, la velocidad que te prometen no es un argumento de venta. Es una responsabilidad. La pregunta no es qué modelo usan. Es quién hace de juez, y se concreta en cuatro preguntas: qué tests protegen lo que te entregan, de dónde salen esos tests (del requisito o del código), qué bloquea una entrega cuando algo está en rojo, y quién revisa el cambio cuando el agente toca un test.
Daniel responde en vídeo a las diez preguntas de este artículo: cómo empieza una tarea real, qué se le deja al modelo y qué no, qué pasa cuando el agente toca el test para ponerlo en verde, y qué debería preguntar cualquier empresa a su proveedor sobre cómo verifica el código generado con IA.
Escrito por
Daniel Pereira
Arquitecto de sistemas en Origen
