Errores de los asistentes de programación con IA y cómo evitarlos

La mayoría de los errores de los asistentes de programación con IA empiezan antes de generar código: la tarea es vaga, las restricciones están ocultas o nadie define cómo se validará el resultado. La prevención no consiste en evitar la IA. Consiste en dar al asistente un problema de ingeniería mejor que resolver.

Estos son los patrones de fallo que vuelven arriesgados los cambios técnicamente válidos, junto con un hábito concreto que evita cada uno.

“Mueve el botón a la barra lateral” le dice a un asistente dónde colocar algo, no por qué falla la ubicación actual.

Prevención: Indica primero el problema de la persona usuaria y el resultado.

Problema: El selector de temas compite con la navegación global, pero las
personas lo usan al comparar lecciones dentro de un curso.

Resultado: Haz que el cambio de tema sea fácil de encontrar junto a la navegación
del curso sin cambiar las acciones globales de la barra de navegación.

Ahora el asistente puede cuestionar la elección de ubicación si otro patrón para pantallas pequeñas es más seguro.

“Limpia el flujo de autenticación” invita a un diff grande. El asistente puede tocar proveedores, rutas, pruebas y llamadas a API porque no ve un límite.

Prevención: Nombra el primer límite y los no objetivos.

Inspecciona únicamente el callback de inicio de sesión y sus pruebas directas.
No cambies la vinculación de cuentas, la facturación ni los guardias de rutas a
menos que la evidencia muestre que el callback no puede corregirse de forma
aislada.

Si el trabajo realmente cruza un límite, el asistente debe explicar por qué antes de ampliarlo.

Un asistente no puede inferir todas las reglas del producto a partir de un componente. Puede introducir una ruta exclusiva del servidor en una aplicación estática, romper una ruta que conserva la configuración regional o duplicar un escritor de estado.

Prevención: Incluye los invariantes esenciales en el prompt o en una guía de proyecto duradera.

Conserva la exportación estática, la navegación con configuración regional activa,
los nombres de eventos de analítica existentes y el escritor único actual para las
preferencias de notificaciones.

Mantén la lista breve y específica. Una larga lista de deseos es menos útil que unos pocos contratos exigibles.

El código generado puede compilar y aun así tener la transición de estado, la ruta de error, el comportamiento de accesibilidad o el límite de seguridad equivocados.

Prevención: Exige un plan de validación antes de implementar.

Enumera las pruebas enfocadas, la comprobación de tipos y el escenario manual que
demostrarían este cambio. Explica qué comportamiento cubre cada comprobación y qué
sigue sin verificar.

Ejecuta las comprobaciones. Revisa el diff. Recorre la ruta de la persona usuaria. La salida de la IA es una propuesta, no un criterio de lanzamiento.

Un diff grande oculta si el error real se corrigió. Es difícil de revisar y casi imposible de revertir con seguridad.

Prevención: Solicita una secuencia de puntos de control pequeños.

Primero reproduce y explica el fallo. Después realiza únicamente la corrección de
estado y añade la prueba de regresión. No refactorices componentes relacionados
hasta que la prueba enfocada pase y se revise el diff.

El cambio más pequeño puede revelar que la refactorización planificada no era necesaria.

“Haz esta página más rápida” puede producir caché, memoización o división de código que oculta el cuello de botella real y crea nuevos riesgos de invalidación.

Prevención: Pide medición y alternativas.

Identifica si la ralentización está en la red, el cálculo o el renderizado. Indica
la medición, la línea base y el impacto esperado antes de proponer una optimización.
No añadas caché persistente hasta que se definan la vigencia y la invalidación.

El trabajo de rendimiento debe cambiar un coste medido, no limitarse a añadir una técnica conocida.

Un asistente puede eliminar una barra lateral de escritorio para mejorar el diseño móvil o simplificar un flujo del que dependen las personas. El código puede estar limpio mientras el producto empeora.

Prevención: Nombra las personas, el flujo de trabajo y el comportamiento que deben permanecer.

Los estudiantes en móviles necesitan más espacio horizontal. Los estudiantes de
escritorio dependen de la barra lateral para navegar por el curso. Mejora el diseño
móvil mientras conservas el flujo de trabajo de escritorio y su ruta de teclado.

Esto convierte “elimina la barra lateral” en una restricción de diseño real.

Los incidentes de producción crean urgencia, pero la urgencia no es una razón para dejar que un asistente adivine a partir de un síntoma.

Prevención: Usa la secuencia de evidencia a validación:

Evidencia -> hipótesis -> verificación -> corrección más pequeña -> prueba de
regresión -> comprobación de despliegue seguro

Incluye registros con valores sensibles eliminados, pasos de reproducción, entorno, cambios recientes, comportamiento esperado y comportamiento observado. No apliques parches generados a producción a ciegas.

Problema: [¿A quién afecta y qué está ocurriendo?]
Alcance: [¿Qué se debe inspeccionar primero?]
Resultado: [¿Qué resultado observable se necesita?]
Restricciones: [¿Qué no debe cambiar?]
Evidencia: [Prueba, registro, captura de pantalla, salida de comando o reproducción.]
Criterios de aceptación: [¿Cómo sabremos que funcionó?]
Validación: [Pruebas, comprobaciones manuales o mediciones.]

Cuestiona el supuesto antes de editar. Si la solución solicitada no está respaldada
por la evidencia, explica la alternativa más segura.

Para ver un desglose completo de esta estructura, lee cómo escribir mejores prompts para IA. Para patrones de implementación del día a día, usa ingeniería de prompts para desarrolladores. Cuando haya un incidente, sigue las plantillas de prompts para depurar problemas de producción.

La salida de la terminal también es evidencia. Practica un flujo de trabajo de línea de comandos en el navegador antes de codificarlo en un informe de error, una prueba o un prompt de automatización.