Seguramente te ha pasado algo así: le pides una funcionalidad nueva a tu agente, este obedece sin protestar… y, justo cuando parecía que todo iba en línea recta, te coge el volante, pega un giro elegante y deja marcas de neumático por zonas del código que nadie le había señalado.
Trabajar con IA acelera muchas tareas, pero también introduce un riesgo que no siempre se ve al principio: empezar resolviendo un problema y terminar construyendo otra cosa. A veces la desviación es pequeña. Otras veces afecta al alcance, a la arquitectura o incluso al criterio de calidad.
Ese fenómeno tiene nombre: drift.
Qué significa realmente el drift
Cuando hablamos de drift en desarrollo de software con IA, nos referimos a una desviación progresiva respecto a la intención original.
Esa intención rara vez es una única instrucción aislada. En un mismo prompt podemos estar pidiendo varias cosas al mismo tiempo: resolver una necesidad de negocio, respetar un alcance concreto, no romper el contexto técnico del proyecto, mantener ciertos criterios de calidad y seguir el estilo de implementación del equipo.
Por ejemplo, cuando pedimos “añade esta validación sin cambiar la arquitectura actual y manteniendo el comportamiento existente”, no estamos dando una sola orden. Estamos combinando objetivo, límite, contexto y criterio de aceptación.
La parte importante es esta: cuantas más dimensiones debe interpretar el sistema, mayor es el espacio en el que puede desviarse.
No hace falta que la IA “se equivoque” de forma evidente. En un sistema no determinista basta con que priorice una de esas dimensiones por encima de otra, rellene huecos por su cuenta, extrapole demasiado u optimice algo que nadie le pidió optimizar.
Por eso el resultado puede parecer razonable en local y aun así estar mal respecto al encargo real.
Por qué importa tanto cuando usamos IA
En desarrollo tradicional, una desviación grande suele hacerse visible antes porque requiere más pasos manuales. Con IA, en cambio, muchas decisiones aparecen comprimidas en muy poco tiempo.
Eso tiene ventajas claras, pero también una consecuencia práctica: es más fácil aceptar cambios plausibles sin revisar si siguen alineados con el problema original.
El drift suele sentirse de una forma muy concreta: la IA avanza rápido, genera una solución que parece buena, pero al revisar notas que algo no encaja. No es necesariamente un error evidente. No siempre falla un test. A veces es más incómodo que eso: tienes que reconstruir mentalmente qué pediste, qué asumió el sistema y en qué curva empezó a torcerse el trayecto.
Ahí aparece el desgaste. La sensación de haber ganado velocidad generando código, pero haberla perdido revisando, deshaciendo o intentando entender por qué hay huellas en módulos, componentes o decisiones técnicas que ni siquiera estaban en la ruta.
El drift importa porque suele degradar una de estas tres cosas:
- el alcance, cuando la solución hace más o menos de lo pedido,
- la coherencia técnica, cuando introduce patrones que no encajan con el proyecto,
- la calidad, cuando aparenta estar terminado pero no cumple criterios reales.
Un ejemplo corto y muy común
Imagina esta petición:
“Añade validación al formulario de registro para evitar envíos vacíos y muestra errores claros al usuario. No cambies la arquitectura actual.”
La tarea empieza bien. La IA añade validaciones básicas y mensajes visibles. Pero en la misma iteración también decide, ya que está con las manos en el volante:
- mover la lógica a una nueva capa de abstracción,
- sustituir componentes existentes por otros distintos,
- introducir una librería nueva para formularios,
- y renombrar partes del flujo “para dejarlo más limpio”.
El resultado puede parecer incluso más sofisticado que antes. El problema es que ya no está resolviendo solo la validación. Ha aprovechado la maniobra para invadir alcance y tomar decisiones técnicas por su cuenta.
También ocurre en pequeño. Por ejemplo:
- un prompt pide refactorizar sin cambiar comportamiento y termina alterando casos borde,
- una mejora visual acaba tocando copy o estructura de navegación,
- una corrección puntual introduce un patrón que el equipo no usa en el resto del código.
Ese es el tipo de drift que más desgaste genera: el que parece útil mientras lo lees rápido, pero cuando bajas la velocidad ves el rastro completo y te toca rehacer parte del camino.
Señales de que hay drift
No siempre se detecta por un error visible. Muchas veces se nota por señales indirectas.
1. La solución crece más rápido que el problema
Si la petición era pequeña y la respuesta introduce varios cambios estructurales, conviene parar. Más código no significa más precisión.
2. Aparecen decisiones que nadie pidió
Nuevas dependencias, nuevas abstracciones, renombres amplios o cambios de patrón son señales típicas. Pueden ser buenas ideas, pero si no estaban en el objetivo, requieren validación explícita.
3. El resultado “suena bien”, pero cuesta justificarlo
Cuando una solución parece correcta por tono o por volumen, pero no es fácil explicar por qué cumple exactamente el encargo, suele haber drift.
4. Se pierde el contexto original en iteraciones sucesivas
Esto ocurre mucho en conversaciones largas. Cada nuevo prompt parte de una versión resumida del anterior y, poco a poco, se diluyen restricciones importantes.
5. Los tests o criterios de aceptación ya no encajan
Una de las señales más útiles es esta: si de repente necesitas cambiar los criterios para que la solución “entre”, quizá no era la solución correcta.
Cómo evitarlo en la práctica
No se trata de desconfiar de la IA de forma automática. Se trata de diseñar el trabajo para que la desviación sea visible cuanto antes.
1. Haz explícita la intención
Cuanto más ambiguo es el encargo, más probable es que el sistema complete huecos por su cuenta.
Es necesario dejar claros estos puntos:
- Qué problema se quiere resolver,
- Qué queda fuera,
- Qué restricciones no se deben tocar,
- Cómo sabremos que el trabajo está bien.
Una instrucción como esta, añadiendo restricciones, suele funcionar mejor que un objetivo genérico:
“Valida campos vacíos en el formulario actual. Mantén la arquitectura existente. No introduzcas librerías nuevas. El cambio debe cubrir nombre, email y contraseña, y conservar el comportamiento actual fuera de esos casos.”
2. Divide el trabajo en objetivos pequeños
Pedir demasiadas cosas a la vez favorece el drift, porque la IA intenta optimizar varias dimensiones simultáneamente.
Es más seguro separar:
- Comprensión del problema (Discovery)
- Propuesta de solución (Plan)
- Implementación (Build)
- Revisión contra criterios (Review)
Objetivos pequeños generan desvíos pequeños, y los desvíos pequeños son más fáciles de detectar y corregir.
3. Introducir checkpoints breves
No esperes al final para revisar si todo sigue alineado.
Funciona mejor añadir paradas intermedias, por ejemplo:
- “Resume lo que vas a cambiar antes de tocar código”,
- “Explica qué partes no vas a modificar”,
- “Lista riesgos o decisiones asumidas”,
- “Compara el resultado con los criterios de aceptación”.
Estos checkpoints obligan a hacer visible el razonamiento y reducen la probabilidad de aceptar una deriva silenciosa.
4. Revisión humana real
La revisión humana no debería limitarse a comprobar si “compila” o si “parece correcto”.
La pregunta útil es otra:
¿Esto resuelve el problema que queríamos resolver, dentro de los límites que habíamos acordado?
Esa revisión es especialmente importante en decisiones de arquitectura, cambios de alcance y supuestos que el sistema haya completado por inferencia.
5. Tests y criterios como ancla
Los tests no evitan todo el drift, pero sí reducen una parte importante: la desviación de comportamiento.
Si además existen criterios de aceptación claros, mejor todavía. Entre ambos crean un marco estable para evaluar el resultado.
En la práctica, ayudan mucho estas referencias:
- Tests que protejan comportamiento esperado
- Ejemplos de entrada y salida
- Definiciones explícitas de “hecho”
- Restricciones técnicas visibles en el prompt o en la tarea
La idea no es burocratizar el trabajo, sino dar a la IA y a la persona revisora un punto fijo contra el que comparar.
6. Revisa lo que no debía cambiar
Una fuente clásica de drift está en los efectos laterales. El cambio principal puede estar bien y, aun así, haber alterado otras partes que nadie quería tocar.
Por eso merece la pena revisar dos preguntas al final:
- ¿Qué ha cambiado?
- ¿Qué no debería haber cambiado y, sin embargo, cambió?
Muchas veces el problema no está en la solución principal, sino en todo lo que se llevó por delante en la maniobra.
Conclusión
El drift en desarrollo de software con IA no es un fallo exótico. Es una consecuencia bastante normal de trabajar con sistemas que completan contexto, infieren intención y generan soluciones plausibles con mucha velocidad.
La buena noticia es que se puede gestionar.
Si defines mejor la intención, reduces el tamaño de cada paso, introduces checkpoints y revisas contra criterios claros, la IA sigue siendo una gran ayuda sin convertirse en una fuente constante de desalineación.
En resumen: no basta con preguntar “¿funciona?”. Cuando trabajamos con IA, también conviene preguntar “¿sigue siendo exactamente el trabajo que queríamos hacer?”.