5 errores que cometes programando con IA y cómo evitarlos

La inteligencia artificial puede ahorrar tiempo al crear una funcionalidad, proponer pruebas o revisar un error. Pero también puede producir código que parece correcto y falla en escenarios importantes. El problema no siempre está en el modelo: muchas veces está en cómo integramos sus respuestas a nuestro proceso de desarrollo.

Estos son cinco errores frecuentes y las prácticas que puedes aplicar para reducirlos.

1. Pedir código sin definir requisitos

«Crea un endpoint para registrar usuarios» parece una solicitud clara. En realidad, faltan decisiones: ¿qué campos son obligatorios?, ¿qué sucede con correos duplicados?, ¿qué permisos se requieren?, ¿cómo se reportan los errores?

Cuando los requisitos no están definidos, la IA puede completar los espacios con supuestos. Esos supuestos quizá no coincidan con las reglas de tu aplicación.

Mejor práctica: proporciona objetivo, restricciones y criterios de aceptación. Por ejemplo:

Implementa POST /users en ASP.NET Core.
- email es obligatorio y debe ser válido.
- si el email ya existe, devuelve 409.
- no registres contraseñas ni tokens en logs.
- agrega pruebas para alta exitosa y correo duplicado.
- antes de modificar código, indica qué archivos revisarás.

No se trata de escribir prompts largos. Se trata de definir lo que significa que la tarea esté terminada.

2. Aceptar código que no entiendes

Un diff generado automáticamente no es una revisión de código. Puede contener condiciones redundantes, errores de concurrencia, consultas ineficientes o cambios que afectan comportamiento existente.

Antes de integrar, responde:

• ¿Qué archivos se modificaron y para qué?
• ¿Qué supuestos introdujo la solución?
• ¿Hay cambios en contratos públicos, validaciones o permisos?
• ¿Qué haría si este código fallara en producción?

Mejor práctica: revisa el diff, pide al asistente que explique sus decisiones y contrasta sus afirmaciones con el código y la documentación. La revisión humana no debería reducirse a pulsar «Accept».

3. Confiar en resultados no verificados

Que un asistente diga «las pruebas pasan» no demuestra que se hayan ejecutado. Puede describir el resultado esperado sin haber tenido acceso a una terminal, sin disponer de dependencias o sin completar los checks.

Mejor práctica: ejecuta validaciones reales y observa sus resultados:

dotnet build

dotnet test

Estos comandos son un punto de partida, no una cobertura completa. Según el proyecto, también necesitarás pruebas de integración, análisis estático, seguridad y comprobaciones de comportamiento.

Si una prueba falla, documenta cuál fue, por qué se considera relacionada con el cambio y qué acción tomaste. Evita pedir «haz que todo pase» sin entender la falla.

4. Compartir demasiado contexto o conceder demasiados permisos

Los modelos pueden necesitar archivos para comprender un problema, pero eso no significa que debas proporcionarles todo el repositorio, credenciales, datos reales de clientes o acceso irrestricto al sistema.

El riesgo incluye filtración de secretos, exposición de información sensible y ejecución de acciones que no eran necesarias para la tarea.

Mejor práctica: usa el principio de mínimo privilegio:

• Comparte archivos y fragmentos relevantes, no información sin relación.
• Excluye credenciales y datos personales de ejemplos y logs.
• Revisa permisos antes de habilitar operaciones de escritura o ejecución.
• Prefiere datos ficticios y entornos de prueba.
• Inspecciona instrucciones y herramientas de terceros antes de utilizarlas.

No confundas un contexto grande con un contexto útil. Un contexto bien seleccionado puede producir mejores decisiones y menos riesgos.

5. Pedir cambios demasiado grandes en un solo paso

«Migra todo el backend, actualiza dependencias y reescribe las pruebas» combina numerosas decisiones en una sola solicitud. Cuando algo falla, resulta difícil identificar la causa y revertir únicamente el cambio problemático.

Mejor práctica: divide la ejecución:

1. Define alcance y criterios de éxito.
2. Prepara un plan de cambios pequeños.
3. Implementa una parte concreta.
4. Revisa el diff y ejecuta pruebas.
5. Crea un commit descriptivo.
6. Continúa con la siguiente parte.

Los commits pequeños no solucionan todos los problemas, pero facilitan la revisión y recuperación.

Diagrama: del error a una mejor práctica

Este diagrama resume hábitos de trabajo, no un sistema que garantice código correcto. Cada proyecto requiere sus propias verificaciones.

Caso práctico: agregar validación a un endpoint

Imagina que trabajas en una API .NET y necesitas evitar correos duplicados al registrar una cuenta. Un flujo prudente sería:

Una validación simple antes de insertar puede no ser suficiente bajo concurrencia. En una implementación real, evalúa también una restricción de unicidad en la base de datos y cómo traducir su error a una respuesta apropiada. Este es el tipo de detalle que puede pasar desapercibido cuando aceptamos código sin revisarlo.

Beneficios y límites de programar con IA

La IA puede ayudar a acelerar tareas repetitivas, explorar alternativas y redactar pruebas. Su desempeño depende del contexto, las herramientas disponibles y la complejidad del problema. Las sugerencias pueden estar desactualizadas, ser inseguras o no cumplir las reglas del negocio.

Usarla bien exige conservar prácticas fundamentales de ingeniería: especificaciones claras, revisión, pruebas reproducibles, seguridad y cambios incrementales.

Conclusión

No necesitas dejar de programar con IA para reducir riesgos. Necesitas trabajar con un proceso que puedas explicar y verificar. Define el objetivo, revisa lo que cambió, prueba lo que importa, limita los permisos y avanza en pasos pequeños.

La IA puede escribir el código. La responsabilidad de integrarlo sigue siendo nuestra.

En la serie BoricuaCoder continuaremos profundizando en las herramientas y decisiones que hacen más confiable el desarrollo asistido por IA.