Box, box: programar con IA no te da permiso para dejar de pensar

Llevo unas semanas dándole vueltas al ritmo al que estamos desarrollando software desde que herramientas como GitHub Copilot, Claude Code y compañía se han sentado con nosotros en la mesa. Y sí, aceleran. A estas alturas negarlo sería como discutir que el fuego quema o que una daily mal llevada puede durar más que una migración de SharePoint.

Pero también me está quedando cada vez más claro que esa aceleración tiene trampa. La IA te ayuda a escribir código más rápido, sí, pero también puede empujarte a una especie de desconexión peligrosa: empiezas a aceptar cambios que “parecen bien”, confías en que lo que ha generado hace lo que crees que hace, y cuando quieres darte cuenta estás conduciendo un coche a toda velocidad sin tener realmente las manos en el volante.

No estoy diciendo nada especialmente exótico. Estoy describiendo algo que muchos estamos viendo ya en el día a día: código que compila, tests que incluso pasan, pero cuyo comportamiento real, su seguridad o su coherencia con la arquitectura del proyecto quedan bastante más en el aire de lo que nos gusta admitir.

El problema no es correr, es correr sin enterarte de por dónde vas #

Que la IA escriba código deprisa no es el problema. El problema empieza cuando confundimos velocidad de tecleo con velocidad de entrega de software bien acabado, son dos cosas muy distintas.

Una herramienta puede darte en minutos un endpoint, su DTO, sus tests y una capa de acceso a datos. Fantástico. La pregunta incómoda es otra: ¿eso encaja con el dominio? ¿respeta las restricciones del negocio? ¿mantiene las convenciones del equipo? ¿cierra bien los agujeros de seguridad? ¿o simplemente produce una versión bastante convincente de “algo que parece una solución”? Ahí es donde, en mi opinión, nos estamos equivocando bastante.

Durante años nos acostumbramos a que el cuello de botella era escribir código. Ahora el cuello de botella es entender bien lo que queremos construir, dar contexto útil, revisar con criterio y validar sin autoengañarnos. Y claro, como los humanos somos muy de irnos a los extremos, hemos pasado de controlar demasiado el código a delegarlo con una alegría que roza el deporte de riesgo.

Lo que dicen los estudios y lo que ya estamos viendo #

Hace poco estuve leyendo el estudio de Himanshu Joshi, Romilla Syed y Shivani Shukla sobre el impacto de las herramientas de generación de código basadas en IA en la seguridad del software. Y no deja precisamente una sensación de “bah, esto ya se arreglará solo”. Entre otras cosas, el estudio apunta a varios problemas bastante serios:

• el porcentaje de vulnerabilidades puede crecer de forma notable a medida que iteramos con la IA
• no todos los estilos de prompting fallan igual; algunos empujan más a errores concretos
• la complejidad extra que introduce el modelo suele correlacionar bastante bien con más superficie de fallo
• incluso prompts que teóricamente buscan “mejorar la seguridad” pueden terminar metiendo errores criptográficos o lógicas inseguras

Traducido al castellano no académico: pedirle a la IA que te “mejore” algo no implica que el resultado sea más seguro. A veces implica exactamente lo contrario, solo que con más capas, más abstracciones y un bonito olor a productividad.

Y esto conecta bastante con el artículo Thoughts on slowing the fuck down, que conocí escuchando a Bruno Capuano en su podcast No tiene nombre. Zechner critica algo que a mí me parece bastante evidente en cuanto has usado agentes de forma intensiva durante unas semanas: producir muchísimo código muy deprisa no significa producir software sano.

De hecho, muchas veces significa producir un sistema más frágil, más incoherente y más difícil de mantener. Un sistema que hoy parece ir fino y dentro de tres semanas parece montado por un comité formado por cinco modelos distintos, dos prompts contradictorios y una persona que aprobó el PR mientras calentaba el café.

La IA no suele fallar donde miras primero #

Ese es uno de los problemas más traicioneros. Cuando la IA mete la pata, muchas veces no lo hace de una forma escandalosa. No suele dejarte un comentario que diga “hola, aquí te he colado una vulnerabilidad”. Lo hace con sutileza:

• una validación que parece razonable, pero deja pasar un caso que negocio no quería
• una comprobación de permisos incompleta
• un flujo feliz impecable con una gestión pésima de errores
• una decisión de arquitectura aparentemente inocente que duplica responsabilidad en tres capas
• una abstracción innecesaria que hace el código más bonito y bastante peor

Ese es el terreno favorito del problema: lo plausible. Porque la IA genera cosas plausibles. Y cuando algo es plausible, cansa más revisarlo bien. El cerebro tiende a decir “bueno, esto más o menos está”. Y en ese “más o menos” es donde luego pasan cosas divertidísimas, siempre que no seas tú quien esté de guardia en producción.

Dicho de una forma más visual: el peligro empieza cuando confundimos “suena razonable” con “está bien”. Y esa confusión, con IA por medio, aparece antes de lo que nos gusta admitir.

Bajar el ritmo no significa volver a picar piedra #

Aquí conviene dejar algo claro para no caer en la caricatura fácil. Yo no estoy defendiendo volver a escribir todo a mano como si estuviéramos en una cruzada romántica contra el autocompletado. No tendría ningún sentido. La IA bien usada aporta muchísimo valor:

• acelera tareas repetitivas y de poco valor diferencial
• ayuda a explorar soluciones y alternativas con rapidez
• reduce bastante el coste de arrancar pruebas de concepto
• puede servir como apoyo documental o de refactor si le das el contexto correcto
• en tareas acotadas, con buenas restricciones, suele rendir francamente bien

El problema no es usarla, el problema es usarla como sustituto de nuestro criterio. La IA no es un reemplazo del juicio humano, es una herramienta que amplifica. Si el contexto es pobre, amplifica el ruido. Si el objetivo está mal definido, acelera en la dirección equivocada. Si la revisión es superficial, te ayuda a meter problemas a una velocidad preciosa.

El equilibrio, para mí, pasa por volver a subir de nivel #

Aquí es donde enlazo con algo sobre lo que ya he escrito en otros artículos, como Spec Driven Development o Context Engineering. Sí, ayudan. Y mucho. Tener mejor especificación y mejor contexto reduce ruido y hace que la IA se acerque más a lo que realmente necesitas.

Pero no deberíamos engañarnos tampoco: puedes subir el nivel del prompt hasta el infinito y seguir necesitando revisión humana seria. Para mí, el equilibrio pasa por asumir varias cosas a la vez:

1. La IA debe trabajar sobre tareas acotadas #

Cuanto más abierta y difusa es la petición, más probable es que el resultado sea una mezcla rara de suposiciones, patrones genéricos y decisiones que nadie tomó de verdad.

Si acotas bien la tarea, das contexto real y marcas restricciones claras, la calidad sube bastante. Si tiras un “hazme esto” al vacío esperando magia industrial, luego no te sorprendas si el invento sale con tornillos de Ikea y frenos de patinete.

2. El humano tiene que seguir siendo el filtro de calidad #

Esto no es negociable. El código generado por IA debe revisarse con el mismo rigor que cualquier otro. Incluso diría que, en algunos contextos, con más mala leche. No vale lo de “bueno, es que lo ha escrito la IA”. Precisamente por eso hay que ser más crítico, no menos.

La IA no firma la incidencia, no entra en la post-mortem y no se come la llamada cuando algo peta en producción a las tres de la mañana. Eso nos sigue tocando a nosotros, que tenemos la mala costumbre de ser responsables de lo que desplegamos.

3. Hay que validar comportamiento, no solo aceptar diffs bonitos #

Uno de los grandes peligros de estas herramientas es que generan cambios convincentes a nivel visual. Un diff bien escrito da una falsa sensación de seguridad. Pero un diff bonito no demuestra nada.

Lo que demuestra algo sigue siendo lo de siempre:

• pruebas con intención
• validación funcional real
• revisión de diseño y de seguridad
• observación de efectos colaterales
• comprobación de que la solución resuelve el problema correcto y no uno inventado

4. El cuello de botella de la revisión es real #

Y aquí hay que ser honestos. Ya lo comentaba Alberto Díaz en un post de LinkedIn: la IA puede generar cambios mucho más rápido de lo que una persona puede revisarlos con garantías.

Eso crea una tensión bastante fea. Porque cuando tienes una pila de PRs o de cambios sugeridos creciendo sin parar, aparece la tentación de hacer un Jim Carrey en Como Dios: te tapas un poco los ojos, aprietas el botón de aprobar y que el universo reparta suerte.

Mal plan. Si la velocidad de generación supera de forma sistemática la capacidad de revisión, no has eliminado un cuello de botella. Solo lo has desplazado a la fase más peligrosa del proceso. Por eso este diagrama no lo metería como adorno: resume bastante bien dónde se empieza a torcer la cosa.

Qué prácticas me parecen razonables #

No tengo una receta mágica, pero sí varias ideas que me parecen sensatas para usar estas herramientas sin convertir el repositorio en una tómbola:

• usar la IA para tareas pequeñas o medianas, con límites claros y criterios explícitos
• exigir contexto mínimo antes de pedir cambios que toquen varias capas o decisiones de arquitectura
• separar generación de código y aceptación de código como dos actividades distintas
• endurecer la revisión en seguridad, permisos, validaciones, concurrencia y tratamiento de errores
• limitar el tamaño de los cambios generados por agentes cuando no hay tiempo real para revisarlos bien
• apoyar la revisión con tests, checklists y validaciones automáticas, pero sin fingir que eso sustituye el juicio técnico
• revisar no solo si funciona, sino si encaja con el sistema y si alguien podrá mantenerlo dentro de dos meses sin llamar a Tom Cruise

Y añadiría una más, que me parece clave: normalizar el derecho a frenar. Parar una iteración, recortar alcance, pedir una spec mejor o devolver un PR generado por IA no es ser un aguafiestas. Es hacer ingeniería.

Mi conclusión a día de hoy #

Creo que el error no está en adoptar IA para desarrollar software. El error está en adoptar velocidad sin disciplina.

Estamos tratando herramientas potentísimas como si fueran solo una versión más rápida del autocompletado, cuando en realidad cambian la forma en la que se produce el código, se multiplica la complejidad y se cuelan fallos difíciles de ver. Y si eso cambia, nuestros mecanismos de control también tienen que cambiar.

Bajar el ritmo no es renunciar a la productividad. Es evitar que la productividad aparente nos destroce la seguridad, la mantenibilidad y la coherencia del sistema.

La IA puede ser una ayuda brutal. Lo es. Pero sigue siendo una herramienta. No un sustituto del criterio, ni del diseño, ni de la responsabilidad. Y cuanto antes nos lo recordemos todos, mejor.

Porque sí, podemos correr mucho. La cuestión no es solo llegar antes. La cuestión es llegar enteros, entender qué hemos construido y no descubrir dentro de un mes que la supuesta productividad era deuda técnica con esteroides.

Fuentes y referencias #

• The Impact of AI Code Generation on Software Security: An Empirical Study
• Thoughts on slowing the fuck down
• No tiene nombre

** ¡Have fun & enjoy coding, con IA! 🚀 **