Problemas comunes al programar con IA:10 soluciones
Problemas comunes al programar con IA, descifrados: qué ves, lo que ocurre por debajo, la solución exacta y el prompt que te desatasca. Los 10 más comunes.
Cuando te atascas programando con IA, es uno de los problemas comunes al programar con IA, casi nunca uno nuevo. Los mismos diez escenarios explican casi todos los momentos de "no tengo ni idea de qué hacer ahora" que vive un fundador sin perfil técnico, y cada uno tiene una causa conocida y una solución conocida. Desatascarse no es una hazaña. Es reconocer patrones.
Esta es la selección de los diez más frecuentes de una lista de veinte escenarios de atasco que guardo para los alumnos del curso AI Product Builder: los que aparecen una y otra vez. Encuentra tu síntoma en la tabla, entiende qué ocurre de verdad, aplica la solución. Si aún no has aprendido a leer los mensajes de error en la consola del navegador, hazlo primero: convierte cada escenario de abajo de un misterio en un diagnóstico.
Por qué te atascas (y por qué nunca es al azar)
Todo escenario de atasco tiene una de tres raíces. O tu entorno se desajustó (la base de datos no está sincronizada con el código, falta un ajuste, una caché está obsoleta), o tu código tiene un defecto concreto (una errata, una comprobación ausente, una importación errónea), o tus datos no son lo que crees (filtrados, en la cuenta equivocada, marcados como inactivos). El código generado por IA añade un giro: el código a menudo funciona; lo que se rompe son las suposiciones que lo rodean.
Por eso "inténtalo de nuevo" rara vez funciona y por eso lo sistemático vence a lo frenético. Identifica el síntoma, comprueba la raíz, aplica la solución.
Los 10 problemas comunes al programar con IA, descifrados
| Lo que ves | Lo que ocurre de verdad | La solución |
|---|---|---|
| 400 Bad Request, "column does not exist" | El código espera una columna de base de datos que nunca se creó: código y base de datos no están sincronizados | Aplica tus migraciones de base de datos pendientes y comprueba la tabla en tu panel de Supabase para confirmar que la columna existe |
| Los datos existen pero no aparecen | Los datos se están filtrando: indicador de inactivo, estado de borrador o pertenecen a otra cuenta | Revisa la fila en el panel de tu base de datos: mira indicadores como is_active y la cuenta a la que pertenece |
| 401 Unauthorized | Tu sesión caducó o te desconectaron | Cierra sesión y vuelve a entrar; si persiste, borra los datos del sitio en tu navegador e inicia sesión de cero |
| 403 Forbidden o 406 Not Acceptable | Has iniciado sesión, pero las reglas de seguridad de la base de datos (RLS) bloquean la operación | Revisa tu rol de usuario y las políticas de seguridad de esa tabla en el panel de Supabase |
| Duplicate key violation | Estás creando algo con un nombre o una dirección que ya existe: deben ser únicos | Usa un valor distinto o actualiza el registro existente en lugar de crear uno nuevo |
| Cannot read property of undefined | El código se ejecuta antes de que lleguen los datos de la base de datos | Pídele a la IA que añada una comprobación de carga antes de usar los datos |
| Module not found | Una errata en la ruta de importación, un archivo que no existe o un paquete que nunca se instaló | Revisa la ortografía y las mayúsculas exactas de la ruta; ejecuta el comando de instalación; reinicia el servidor de desarrollo |
| Build failed al desplegar | Errores de tipos ignorados en local, o ajustes (variables de entorno) que faltan en la plataforma de hosting | Ejecuta primero el build en tu máquina para ver el error real; copia todas las variables de entorno al panel del hosting |
| Desplegado, pero la web muestra la versión antigua | Tu navegador o la CDN sirve una copia en caché de la web antigua | Recarga forzada (Cmd + Shift + R); prueba en una ventana privada; vuelve a desplegar con la caché limpia |
| Cambié el código y no pasa nada | El servidor de desarrollo no está funcionando, el archivo no se guardó o editaste el archivo equivocado | Comprueba que la terminal ejecuta el servidor, guarda el archivo, recarga a la fuerza y confirma después que editaste el archivo al que apunta realmente el error |
Tres problemas que en realidad son uno
Mira otra vez las filas dos, tres y cuatro. "Los datos no aparecen", "401" y "403" parecen tres desastres distintos, pero son una misma familia: identidad y permisos. La base de datos siempre hace las mismas tres preguntas: quién eres, a qué cuenta perteneces y si tienes permiso para hacer esto. Cuando alguna respuesta es incorrecta, aparece uno de esos tres síntomas.
Así que depúralos en ese orden. Primero: ¿he iniciado sesión de verdad? Segundo: ¿estos datos están en mi cuenta, o los creé con otro correo? Tercero: ¿la política de seguridad de esta tabla permite a mi rol hacer esto? Nueve de cada diez veces, nunca llegas a la tercera pregunta.
Funciona en tu máquina, se rompe en producción
El escenario más desmoralizante merece su propia sección: todo funciona en local, despliegas y la web en vivo está rota. Nada "salió mal": local y producción son, simplemente, entornos distintos. Ajustes distintos, base de datos distinta, modo de build distinto. La lista de comprobación:
- Primero, las variables de entorno. Cada ajuste que lee tu código debe existir en el panel de la plataforma de hosting, no solo en tu máquina. Esta es la causa con más frecuencia que todas las demás juntas.
- Comprueba a qué base de datos apuntas. Tu aplicación en vivo debe usar la dirección de tu base de datos de producción, no la de desarrollo.
- Lee los logs del despliegue. Tu plataforma de hosting registra errores que nunca aparecen en tu máquina.
- Haz el build en local como en producción. Ejecuta en tu máquina el comando de build de producción: si falla ahí, has encontrado tu fallo sin otro ciclo de despliegue.
El prompt que te desatasca
Cuando la tabla no lo resuelve, entrégale el problema a la IA como es debido. Los ruegos vagos producen suposiciones vagas, y una IA que adivina puede empeorar las cosas, como mostré en cómo la IA sabotea tu código. El prompt para desatascarse tiene cuatro partes:
Estoy atascado en [lo que intentabas hacer]. Lo que esperaba: [resultado esperado]. Lo que ocurre en realidad: [síntoma exacto]. Mensaje de error completo: [pégalo, con archivo y línea]. Lo que ya probé: [tu lista]. Diagnostica la causa más probable antes de proponer una solución.
Esa última frase importa. Obligar a diagnosticar primero evita que la IA dispare arreglos al azar contra tu código: el equivalente en depuración de un médico que receta antes de examinar. Y un hábito evita que te pase la mitad de este artículo: haz commit del código que funciona antes de cada experimento, de modo que "todo funcionaba y ahora está roto" siempre tenga una salida de un solo comando.
El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →Preguntas frecuentes
¿Qué debo hacer primero cuando me atasco?
Abre la consola del navegador y lee el error real: así se lee cualquier error en 30 segundos. Después mira la terminal donde se ejecuta tu servidor de desarrollo. Entre esos dos sitios, la causa real casi siempre está escrita para ti; la habilidad está en mirar antes de adivinar.
Ayer todo funcionaba y no cambié nada. ¿Qué pasó?
Algo cambió; simplemente no lo notaste. Los sospechosos habituales: descargaste código nuevo sin actualizar las dependencias o la base de datos, una fusión salió mal o un archivo se revirtió por accidente. Pregúntale a tu control de versiones qué cambió desde el último estado que funcionaba y restaura desde ahí. Por eso hacer commit a menudo del código que funciona es el seguro más barato del software.
¿Cuándo debo dejar de depurar y pedirle ayuda a la IA?
Tras una pasada sistemática: lectura de la consola, síntoma contrastado con los escenarios comunes, un arreglo intentado. Si eso no lo resuelve, pega todo el contexto (error, expectativa, lo que probaste) con el prompt para desatascarse de arriba. Veinte minutos de adivinar tozudamente en solitario valen menos que dos minutos de preguntar bien preparado.
¿Estos problemas son señal de que no debería construir sin un desarrollador?
No: todo desarrollador del planeta se topa con estos mismos escenarios; solo que los ha visto las veces suficientes para reconocer los patrones. Ese reconocimiento se aprende en semanas, no en años. Las diez filas de arriba son la mayor parte de lo que significan los "años de experiencia" en la depuración del día a día.
¿Hasta qué punto estás atrapado?
Haz el Índice de Asfixia Corporativa, la evaluación gratuita para saber si estás listo para ser solopreneur.