Errores de la IA en producción y cómo evitar cada uno
Los errores de la IA en producción: qué hizo mal Claude, el patrón correcto y la instrucción exacta que evita que cada uno de los 10 errores se repita.
Los errores de la IA en producción son predecibles y están documentados: escribe código que funciona en la demo y falla en vivo. Mientras construía mi propia plataforma con Claude, llevé un registro de cada error que necesitó corrección: 28 lecciones recurrentes, cada una con la instrucción exacta que la previene. Estos son los diez que más cuestan cuando se cuelan.
El objetivo de esta lista no es asustarte para que dejes de desarrollar con IA. Es justo lo contrario: como los errores son predecibles, son evitables, con una frase en tu prompt o una regla permanente en las instrucciones de tu proyecto. No necesitas escribir el código correcto. Necesitas reconocer el patrón incorrecto y saber qué decir.
Por qué la IA comete siempre los mismos errores
La IA optimiza para el camino feliz: la versión de tu funcionalidad en la que los datos existen, el usuario ha iniciado sesión, nada falla y solo un cliente usa la aplicación. Esa versión luce de maravilla en una demo. La producción es todo lo demás: las sesiones caducan, dos usuarios hacen clic a la vez, faltan datos y el cliente A nunca debe ver los registros del cliente B.
La IA no se salta esto por descuido. Se lo salta porque no se lo pediste, y, a diferencia de un desarrollador senior, no completa los requisitos no expresados con la experiencia. Estos cuatro comportamientos de sabotaje son una lista relacionada pero distinta que traté por separado; los diez de hoy tratan de lo que el código de calidad de producción necesita y la IA omite por defecto.
Los 10 errores de la IA en producción, el patrón correcto y la instrucción
| Lo que hizo Claude | El patrón correcto | Cómo indicárselo |
|---|---|---|
| Creó un servicio duplicado para una funcionalidad que ya existía | Una única fuente de verdad por dominio: amplía el servicio existente | "Antes de crear un archivo nuevo, comprueba si existe un servicio similar y amplíalo" |
| Dejó que los componentes de la interfaz hablaran directamente con la base de datos | Tres capas: los componentes usan hooks, los hooks usan servicios y solo los servicios tocan la base de datos | "Nunca importes el cliente de la base de datos en los componentes: sigue la arquitectura de 3 capas" |
| Usó tipos ENUM rígidos para estados y categorías | Tablas de consulta que puedes ampliar sin cambiar código | "Sin enums: crea una tabla de consulta con código, nombre visible, orden y un indicador de activo" |
| Creó claves foráneas sin índices | Cada clave foránea lleva un índice; las combinaciones de consulta habituales llevan índices compuestos | "Toda columna de clave foránea debe tener un índice" |
| Construyó tablas sin una columna de organización | Multi-tenancy desde el día 1: cada tabla de negocio pertenece al cliente que es dueño de los datos | "Toda tabla de negocio lleva organization_id, not null, como segunda columna" |
| Omitió por completo la seguridad a nivel de fila | RLS activada en cada tabla, con políticas de lectura, inserción, actualización y borrado | "Tras crear cualquier tabla, activa RLS y añade las cuatro políticas por organización" |
| Solo gestionó el camino feliz en los componentes | Cuatro estados en todas partes: cargando, error, vacío y éxito | "Todo componente que obtenga datos debe gestionar los estados de carga, error, vacío y éxito" |
| Dejó que los errores fallaran en silencio | Capturar, registrar con contexto y mostrar al usuario la opción de reintentar | "Toda función asíncrona gestiona errores: regístralo, lanza un error comprensible y muestra un reintento" |
| Borró datos de forma permanente al pedírselo | Borrado lógico: marcar los registros como eliminados, conservar los datos y permitir deshacer | "Nunca borres datos de negocio de forma definitiva: asigna deleted_at y deleted_by, y fíltralos en las consultas" |
| Ejecutó escrituras de varios pasos sin una transacción | Las escrituras relacionadas tienen éxito o fallan juntas, nunca a medias | "Estas escrituras deben ser atómicas: o todas tienen éxito o se revierten todas" |
El conjunto completo de 28 lecciones, que incluye seguridad de tipos, registros, accesibilidad, identificadores fijos en el código y cobertura de pruebas, está dentro del curso AI Product Builder, cada una con código de antes y después y el prompt para copiar y pegar.
El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →Los dos errores que pueden acabar con tu negocio
Ocho de los diez te cuestan tiempo. Dos pueden costarte la empresa.
La falta de multi-tenancy y de seguridad a nivel de fila son máquinas de filtrar datos. Sin una columna de organización en cada tabla, los datos de todos tus clientes viven en un único montón sin dividir, y solo la buena suerte en el código de la aplicación evita que el cliente A vea los registros del cliente B. La seguridad a nivel de fila es el muro a nivel de base de datos que aguanta incluso cuando tu código tiene fallos, y tu código los tendrá. La IA se salta ambas cosas si no se lo dices, porque nada en "constrúyeme un gestor de proyectos" dice que las empresas de otras personas también vivirán en esta base de datos.
Corregirlo después es brutal: añadir la columna de organización más tarde implica migrar cada tabla, rellenar cada fila, actualizar cada consulta y volver a probarlo todo. Una frase en el prompt original, o una semana de cirugía de migración después. Elige la frase.
Convierte las correcciones en reglas permanentes
Corregir a la IA error por error es nadar contra la corriente. La jugada que se acumula es escribir cada corrección en el archivo de instrucciones de tu proyecto, para que cada sesión futura empiece con las reglas ya cargadas; expliqué el mecanismo en el único archivo que previene el 90% de los errores de la IA. Un bloque de reglas tan corto como este cambia todo lo que viene después:
Sigue la arquitectura de 3 capas. Toda tabla lleva organization_id, columnas de auditoría y políticas RLS. Sin enums: tablas de consulta. Indexa cada clave foránea. Solo borrado lógico. Todo componente gestiona carga, error, vacío y éxito. Toda función asíncrona gestiona errores.
Diez líneas. Escritas una sola vez. Aplicadas en cada prompt que ejecutes. Esa es la diferencia entre corregir a la IA y dirigirla, que es el verdadero trabajo, como defendí en tú eres el arquitecto.
12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →Preguntas frecuentes
Si la IA comete todos estos errores, ¿es seguro construir con ella?
Sí, porque los errores son consistentes, no aleatorios. Un desarrollador junior comete errores distintos cada semana; la IA comete los mismos diez hasta que escribes la regla que detiene cada uno. Un modo de fallo documentado con una prevención conocida de una línea es un riesgo de ingeniería manejable, no un motivo para contratar a un equipo.
¿Cómo detecto estos errores si no sé leer código con soltura?
Revisa con preguntas, no leyendo línea por línea. Pregúntale directamente a la IA tras cualquier generación: ¿tiene cada tabla una columna de organización y políticas RLS? ¿Los borrados son lógicos? ¿Este componente gestiona los estados de carga, error y vacío? La IA es honesta sobre sus propias omisiones cuando se le pregunta con precisión: la tabla de arriba es, en la práctica, tu lista de revisión.
¿Debo corregir estos problemas en el código que la IA ya escribió?
Prioriza por riesgo. Arregla primero el par de seguridad, el aislamiento por organización y la seguridad a nivel de fila, antes de aceptar clientes reales, porque corregirlos después solo se complica a medida que crecen los datos. Los estados que faltan, los registros y los borrados lógicos se pueden arreglar funcionalidad a funcionalidad según vayas tocando cada pantalla.
¿Dónde van realmente las reglas permanentes?
En un archivo de instrucciones del proyecto que tu herramienta de IA lea al comienzo de cada sesión; en el caso de Claude, un archivo CLAUDE.md en tu proyecto. Cada corrección que hagas se promueve a ese archivo, de modo que se hace exactamente una vez. La configuración lleva minutos y se explica en la guía de CLAUDE.md.
¿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.