Conoces los riesgos de desarrollar usando asistentes de IA como GitHub Copilot o Claude Code?

Si usas Copilot, Claude Code o el asistente que toque en tu IDE, seguramente ya notaste dos cosas:

1. Vas mas rapido.
2. Si te confias, te estampas mas rapido.

Y no lo digo en plan “la IA nos va a quitar el trabajo”. Lo digo en plan ingenieria de trinchera: he visto codigo que en demo parecia impecable y en produccion abria puertas que nadie queria abrir.

El problema no es la herramienta. Es como la usamos #

Cuando trabajamos con asistentes de IA, el riesgo mas frecuente no suele ser un bug exotico. Suele ser algo mucho mas humano:

• Prompt vago
• Contexto incompleto
• Revision superficial
• Sesiones demasiado largas
• Permisos demasiado abiertos

Traducido: pasamos de “vibe coding” a “vibe shipping” en tres pasos, y luego nos sorprende que aparezcan sorpresas en produccion.

Riesgos reales que veo repetirse #

En este articulo me limito a los riesgos que mas claramente veo repetirse en el uso diario de asistentes de desarrollo:

1) Contexto: dar poco contexto y esperar magia #

Este es el clasico. Le pedimos al asistente que haga algo “normal”, pero olvidamos que la palabra normal solo significa algo para nosotros. No para el modelo.

Si pides un alta de usuarios sin hablar de validaciones, reglas de negocio, formato de los datos o restricciones de seguridad, el asistente rellenara huecos. A veces acertara. A veces no. Y cuando no, el resultado puede seguir pareciendo correcto durante demasiado tiempo.

El problema no es solo que falle. El problema es que puede fallar con bastante aplomo.

2) Exceso de confianza: confiar ciegamente en codigo que no has revisado #

Este riesgo no necesita presentacion, pero conviene repetirlo porque sigue pasando todos los dias: el codigo compila, la demo sale y alguien piensa que eso equivale a estar bien.

No equivale. Un asistente puede generar una solucion que haga lo que pediste y, al mismo tiempo, hacer mas cosas de las que querias, mezclar responsabilidades o dejar una base estupenda para la deuda tecnica del proximo sprint.

Aqui entran muchos males conocidos: codigo spaghetti, duplicacion, decisiones pobres de diseno y esa maravillosa sensacion de “esto ya lo arreglara el siguiente que pase por aqui”.

3) Control de costes: disparar el coste sin darte cuenta #

Este riesgo suele ser menos vistoso que un bug, pero tambien duele. Duele en la latencia, en el consumo y en la sensacion de que para cambiar una coma hemos montado una expedicion al Himalaya.

Cuando activamos demasiadas herramientas, metemos demasiado contexto o usamos agentes complejos para tareas pequenas, el flujo parece sofisticado, pero muchas veces solo es caro.

Y no me refiero solo a dinero. Tambien hablo de coste cognitivo: mas espera, mas ruido y mas dificultad para entender que esta pasando realmente.

4) Control de sesiones: estirar demasiado una sesion hasta que deja de tener sentido #

Hay sesiones que deberian haber terminado veinte minutos antes. El asistente empieza centrado, luego le pedimos otra cosa, luego una mas, luego “ya que estas” y al final estamos preguntando arquitectura despues de haber empezado corrigiendo un bug de validacion.

Cuando mezclas demasiados temas en una misma sesion, el contexto se degrada. El asistente arrastra decisiones anteriores, mezcla prioridades y pierde precision. Es como una reunion eterna: nadie recuerda ya por que estabais ahi.

5) Arquitectura: sobreingenieria (matar moscas a canionazos) #

La sobreingenieria tiene algo peligroso: muchas veces parece profesional. Ves capas, factories, providers, adapters, orchestrators y piensas “esto pinta serio”. A veces es serio. Otras veces es una forma elegante de complicar una solucion sencilla.

Con asistentes de IA pasa mucho porque, si no acotas, tienden a proponer estructuras genericas y expansivas. Y claro, si le pides un CRUD de una entidad casi te monta media NASA.

6) Arquitectura: sin criterio #

Este es primo hermano del anterior, pero no exactamente lo mismo. La sobreingenieria es exceso. La arquitectura sin criterio es falta de decision.

Si no defines un patron claro, la division de proyectos, la responsabilidad de las capas o los limites entre modulos, el asistente improvisa. Y cuando improvisa, lo hace con patrones promedio, no con criterio adaptado a tu sistema.

El resultado suele ser una mezcla rara: parte clean architecture, parte servicio utilitario omnipotente, parte carpeta misc con olor a arrepentimiento futuro.

7) Exceso de confianza operativa: poner el modo autopilot y regalar permisos de mas #

Este riesgo es muy actual y bastante menos inocente de lo que parece. Dar permiso al asistente para ejecutar todos los comandos de una sesion sin controlar que va a hacer suena muy productivo hasta que deja de serlo.

En ese modo, cualquier mala interpretacion se convierte en accion: un comando, una modificacion lateral, un cambio de estructura, una instalacion que no querias o un barrido demasiado amplio sobre archivos que no tocaban.

No hace falta ponerse dramatico. Basta con recordar una idea sencilla: automatizar no significa abdicar.

8) Control de costes: elegir el modelo por hype #

Este riesgo se ha vuelto bastante comun: sale un modelo nuevo, vemos benchmark impresionante, y automaticamente lo ponemos para todo. Para todo, incluido lo que no lo necesita.

Usar el ultimo modelo no siempre es mala idea. Usarlo por defecto sin criterio, si. Hay tareas donde la diferencia de calidad es minima, pero el coste y la latencia suben de forma clara.

Una forma practica de evitarlo: elegir modelo por tipo de tarea, no por novedad. Si el trabajo es rutinario, usa un modelo mas ligero. Reserva los mas caros para tareas de alto impacto, alta ambiguedad o razonamiento complejo.

Como bajar el riesgo sin matar la velocidad #

No se trata de usar menos IA. Se trata de usarla mejor.

Checklist minimo antes de mergear codigo generado por IA:

1. Seguridad

• Di claramente que restricciones aplican
• No des por supuesto nada importante

2. Calidad

• Revisa el codigo aunque compile
• Comprueba si hace mas cosas de las que pediste

3. Operacion y coste

• Ajusta herramientas y contexto al tamano real de la tarea
• Reinicia la sesion cuando empiece a mezclar demasiados temas

4. Trazabilidad

• No concedas permisos amplios sin control
• Mantente dentro del alcance pedido

Si no puedes explicar esas cuatro cosas, todavia no deberias hacer merge.

Formato interactivo para equipos y charlas #

Si quieres convertir esto en una sesion util (y no en otra charla de diapositivas bonitas), este formato funciona muy bien en 10-12 minutos:

1. Arranque rapido

• Quien acepto una sugerencia sin leerla entera?
• Quien ha tenido una sesion tan larga que ya no sabia que contexto seguia vivo?

2. Lluvia de casos reales en tres columnas

• Contexto y calidad
• Coste y sesion
• Arquitectura y control operativo

3. Priorizacion por semaforo

• Verde: bajo impacto
• Amarillo: riesgo medio
• Rojo: alto impacto

4. Cierre con tres acciones

• Definir un minimo de contexto para tareas repetidas
• Cortar sesiones largas antes de que se degraden
• No activar autopilot sin limites claros

Un ejemplo rapido para aterrizarlo #

Peticion floja:

“Hazme rapidamente un sistema de alta de usuarios. Decide tu la estructura del proyecto y ejecuta lo que haga falta.”

Respuesta habitual: solucion rapida, capas que nadie pidio, demasiado alcance y demasiado margen para meter ruido en la sesion.

Peticion madura:

“Ayudame a implementar solo el alta de usuarios en esta arquitectura existente. No cambies la estructura del proyecto, no ejecutes comandos sin confirmacion, limita el contexto a los archivos implicados e indica supuestos antes de proponer cambios.”

Misma herramienta, resultado muy distinto. La diferencia no esta en el modelo. Esta en el contexto y en el criterio.

Conclusion #

Los asistentes de IA no sustituyen criterio tecnico. Lo amplifican.

Si el criterio es bueno, aceleran decisiones buenas. Si el criterio es flojo, aceleran errores caros, arquitectura confusa, sesiones descontroladas y automatismos que se vuelven en tu contra.

Por eso, para mi, la pregunta no es “usar o no usar Copilot/Claude Code”. La pregunta real es: “que disciplina de trabajo tienes cuando lo usas?”

Y ahi, guste o no, seguimos siendo nosotros quienes llevamos el volante.