La IA no introduce menos bugs que un humano, los introduce distinto. Aceptar un diff completo sin revisión estructurada es la forma más rápida de acumular deuda técnica invisible.
El código generado por Cursor no falla igual que el código escrito por un humano apurado. Los patrones de error típicos son: lógica que "parece" correcta porque sigue un patrón común pero no encaja con las reglas de negocio específicas del proyecto, manejo de errores genérico que traga excepciones importantes, y duplicación de lógica que ya existía en otro archivo porque el modelo no la encontró en su contexto. Ninguno de estos errores produce necesariamente un fallo visible en desarrollo — aparecen en producción, con datos reales, en el caso borde que nadie probó.
Suena obvio, pero la fricción de Cursor está diseñada para que aceptar sea el camino de menor resistencia (un solo Tab o clic). Fuerza una pausa estructural: revisa el diff completo en la vista de cambios antes de aplicar, no en el chat.
Si el conteo de archivos afectados es mayor al esperado, es señal de que el modelo generalizó más allá del alcance pedido.
Además del review normal (estilo, tests, legibilidad), agrega verificaciones que atacan los errores típicos de LLMs:
- Manejo de errores real, no genérico. Busca bloques try/catch vacíos o que solo hacen console.log(error) sin propagar ni loguear en el sistema de observabilidad del proyecto. - Validación de límites y null-checks. Los modelos a veces asumen el "camino feliz" (arrays no vacíos, campos siempre presentes) y omiten validaciones que el resto del código sí respeta. - Duplicación de lógica existente. Si el modelo escribió una función de validación de email nueva, verifica si ya existe una en utils/ — es un patrón común cuando el contexto no incluyó ese archivo. - Dependencias nuevas no solicitadas. Revisa si se agregó una librería en package.json o composer.json que no discutiste; los modelos a veces "resuelven" un problema instalando algo en vez de usar lo que ya está disponible.
Una vez aplicado el cambio, pide una revisión explícita en un prompt separado, no en la misma conversación donde se generó el código — esto evita que el modelo simplemente confirme su propio trabajo por inercia conversacional.
Esto no reemplaza la revisión humana, pero atrapa una categoría de errores mecánicos antes de que lleguen al revisor humano, que puede enfocarse en decisiones de diseño en vez de detalles sintácticos.
Si el código generado no viene acompañado de tests, escríbelos tú o pídelos explícitamente antes de hacer merge — nunca asumas que "se ve bien" es suficiente. Para lógica de negocio crítica (pagos, autenticación, permisos), exige que el prompt original incluya la generación de tests que cubran casos borde específicos, no solo el caso feliz.
En equipos donde varios desarrolladores usan Composer activamente, agrega una convención simple en la descripción del PR: qué prompt (resumido) generó el cambio principal. Esto no es burocracia — cuando aparece un bug tres semanas después, saber que el código vino de un prompt específico ayuda a diagnosticar si el problema fue instrucción ambigua, contexto insuficiente, o simplemente un caso que nadie consideró.
La regla de oro que ningún equipo debería flexibilizar: el desarrollador que aprueba el merge es responsable del código, sin importar quién (o qué) lo escribió. Cursor es una herramienta que acelera la escritura, no un sustituto de la responsabilidad de entender lo que se está desplegando a producción. Tratar el código de IA con más escepticismo, no menos, que el código propio es la disciplina que separa a los equipos que ganan velocidad real de los que acumulan incidentes.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel