Errores al programar con IA:4 trampas de Claude

Los errores al programar con IA no sabotearán tu código con algo que se rompe. Lo sabotean con código que funciona, durante unos seis meses. Claude se equivoca con total seguridad todo el rato, y la versión peligrosa no es cuando se equivoca de forma evidente. Es cuando se equivoca de forma plausible: código que compila, se ejecuta y parece correcto, construido sobre una suposición errónea acerca de tus datos o de tu lógica de negocio.

Durante once meses construyendo FIKR Space, los mismos cuatro patrones malos seguían saliendo de la IA. Cada uno habría creado un dolor distinto y concreto seis meses después si lo hubiera aceptado. Aquí están en lenguaje llano: qué propone Claude, por qué parece razonable y exactamente qué te cuesta más adelante.

Por qué la IA recurre por defecto a código mediocre

Claude se ha entrenado con millones de bases de código, y la mayoría eran mediocres. Cuando no especificas lo que quieres, obtienes la salida de la base de código mediana: llena de atajos y concesiones que los ingenieros con experiencia nunca aceptarían. Ninguno de esos atajos falla hoy. Todos fallan más tarde, y por eso sobreviven a la revisión de un fundador que solo comprueba si la funcionalidad anda ahora mismo.

Tu trabajo no es escribir el código. Tu trabajo es ser la voz senior de la colaboración: llevar la contraria cuando algo no huele bien, aunque no puedas explicar de inmediato por qué.

Error 1: el blob JSON, un cajón de sastre en lugar de un archivador

Claude te sugerirá guardar datos estructurados como un blob JSON (un campo flexible que contiene todo) en lugar de una tabla de verdad con columnas de verdad. Piensa en ello como tirar tus documentos a un cajón de sastre en lugar de a un archivador. El cajón funciona bien mientras hay diez documentos dentro.

Me pasó en la semana tres. Claude propuso guardar los datos de objetivos estratégicos de los usuarios (objetivos trimestrales, estado de OKR, métricas de alineación) como una columna JSON en la tabla de usuarios. Habría funcionado. Durante unos tres meses. Luego necesité responder una pregunta de negocio básica: muéstrame todos los usuarios cuyo cumplimiento de objetivos del tercer trimestre esté por debajo del sesenta por ciento. Contra un blob JSON, responder eso significa abrir el cajón de cada usuario y leer todo lo que hay dentro antes de poder filtrar, un enfoque que escaló hasta cincuenta usuarios y habría muerto a los quinientos. Arreglarlo más tarde habría implicado migrar seis meses de datos de clientes y reescribir doce servicios. Plantar cara en la semana tres costó una hora extra de conversación de diseño. Reconstruirlo en el mes seis habría costado tres semanas.

Error 2: los enums, grabar en piedra las opciones de hoy

Un enum es un campo cuyos valores permitidos se fijan de antemano, como imprimir la carta de tu restaurante en lugar de escribirla en una pizarra. Claude tiene una fuerte tendencia por defecto hacia los enums para cualquier campo con un conjunto pequeño y conocido de valores: nivel de suscripción, rol de usuario, tipo de notificación. Cada uno parece obviamente fijo en el momento.

Cada uno de los míos acabó necesitando nuevos valores en menos de un año: un nuevo nivel de suscripción, un nuevo rol, una nueva categoría de notificación. Y cambiar un enum en la base de datos exige un ritual de varios pasos: eliminar restricciones, recrear el tipo, actualizar cada fila. Una tabla de consulta (la versión pizarra) es una tabla normal que crece añadiendo una fila. El enum ata la columna a la realidad de hoy; la tabla de consulta acomoda la de mañana. Mismo patrón, distinto valor por defecto. Plántale cara. Exige la tabla de consulta.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Error 3: los tipos any, desactivar la alarma de humo

Todo el trabajo de TypeScript es detectar toda una clase de errores antes de que tus usuarios los vean, comprobando que cada dato tiene la forma que el código espera. Cuando esa comprobación falla con algo complejo, Claude a veces propondrá marcar el dato como any, que significa "deja de comprobar esto". El error desaparece. El build tiene éxito. La funcionalidad se lanza. Acabas de desactivar una alarma de humo, y no pasa nada hasta que hay humo.

Este es el patrón más insidioso porque el síntoma es invisible. Seis meses después cambias algo en otra parte del producto, y el error de tipos que debería haber detectado la rotura no salta, porque en algún punto aguas arriba un any se está tragando la señal en silencio. El error llega a producción. Te enteras por el aviso de un cliente. Cada any que aceptes ahora es una futura tarde de martes dedicada a depurar un problema que el sistema de tipos debía evitar.

Error 4: tragarse los errores en silencio, fallos que nadie oye

El peor de los cuatro. Claude a veces escribirá el equivalente de try { ... } catch (e) { return null }, es decir, "si algo sale mal, no digas nada y devuelve un resultado vacío", y lo llamará gestión elegante de errores. Ese código pasa todos los tests que escribas, porque tus tests no provocan deliberadamente el modo de fallo.

En producción, cuando ocurre el fallo real, la función no devuelve nada. En silencio. El resto del sistema no sabe que algo salió mal. El usuario ve una pantalla en blanco. El error no queda registrado en ningún sitio. No te enteras hasta que un cliente se queja, y ni siquiera entonces puedes rastrear lo ocurrido, porque nunca se lanzó ningún error. Combate esto cada vez: fallos específicos, gestionados de forma específica, registrados a voz en grito. Las cinco líneas de código extra te ahorran la próxima caída.

El patrón detrás de los cuatro errores al programar con IA

La buena noticia: Claude responde bien cuando lo cuestionas. Cuando le dices "no, quiero esto como una tabla aparte, no como un blob JSON, y aquí te explico por qué", reestructura el código con elegancia y a menudo mejora lo que había propuesto. El modelo es colaborativo. Solo tienes que ser la voz senior.

Dos hábitos hacen que plantar cara sea sistemático en lugar de cuestión de suerte. Informa bien a la IA antes de que construya nada: eso es el método PRP. Y nunca dejes que la velocidad sustituya a la estructura: esa es toda la lección de la trampa del vibe coding. Especifica. Plántale cara. Exige la estructura correcta. Cuesta un poco más de tiempo por funcionalidad y te compra una base de código que aún puedes evolucionar en el mes doce, en lugar de una que tienes que reconstruir.

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

¿Por qué el código generado por IA causa problemas meses después?

Porque la IA optimiza para que funcione la petición de hoy, no para cómo evoluciona el código. Entrenada con millones de bases de código mayormente mediocres, recurre por defecto a atajos (blobs flexibles, listas de valores fijas, comprobaciones desactivadas, errores tragados) que pasan todas las pruebas ahora y solo revelan su coste cuando el producto crece o cambia.

¿Cómo detecto código malo de la IA si no sé leer código?

Interroga el cambio y el fallo, no la sintaxis. Pregúntale a la IA: ¿qué pasa cuando necesitemos añadir un valor nuevo aquí? ¿Cómo buscaríamos en estos datos cuando tengamos diez veces más? ¿Qué pasa cuando esta operación falla, adónde va el error? Si las respuestas implican migraciones, reescrituras o "no devuelve nada", plántale cara.

¿Debo dejar que Claude tome mis decisiones de arquitectura?

No. Claude es un implementador brillante y un arquitecto mediocre. Pregúntale si algo debería ser una tabla aparte o una columna JSON y la respuesta suele estar bien, a veces mal y ocasionalmente es genial, y no puedes saber cuál a menos que hayas desarrollado tu propio criterio arquitectónico. Las decisiones de arquitectura son tuyas; las de implementación, de Claude.

¿Plantarle cara a la IA no ralentiza la construcción?

Un poco, por funcionalidad, y es el mejor trato que harás jamás. Plantar cara al blob JSON me costó una hora extra de conversación de diseño en la semana tres. Aceptarlo habría costado tres semanas de reconstrucción en el mes seis, además de migrar seis meses de datos de clientes.