9. Limitaciones de los modelos

9.1 Introducción

En el tema anterior analizamos las ventajas del desarrollo asistido por IA. La misma capacidad que permite obtener una propuesta en pocos segundos puede crear una impresión equivocada: si el resultado está bien escrito, parece completo y utiliza términos técnicos, tendemos a suponer que también es correcto.

Un modelo puede generar una función válida, explicar un error, proponer una arquitectura o modificar varios archivos. Sin embargo, no conoce automáticamente todos los requisitos, no observa necesariamente la ejecución y no comparte la comprensión que una persona construyó sobre el proyecto.

Conocer estas limitaciones no significa rechazar la herramienta. Permite asignarle tareas apropiadas, proporcionar mejor contexto y decidir qué comprobaciones necesita cada respuesta.

9.2 Modelo, aplicación y herramientas no son lo mismo

Cuando hablamos de una “IA que programa” solemos reunir varios componentes bajo un mismo nombre. Distinguirlos ayuda a comprender qué puede observar y hacer realmente el sistema.

Un chat sin acceso al proyecto puede sugerir código, pero no comprobar cómo se integra. Un agente con terminal puede ejecutar pruebas, aunque eso no demuestra que haya comprendido necesidades que nunca fueron escritas.

9.3 Generar una respuesta probable no equivale a comprender

Los modelos de lenguaje producen una salida a partir de patrones aprendidos y del contexto recibido. Pueden relacionar conceptos, seguir instrucciones y resolver numerosos problemas, pero no comprenden el producto de la misma manera que sus usuarios o responsables.

Si pedimos “agregá un estado a cada pedido”, todavía quedan decisiones abiertas:

• Qué estados existen y cuáles son sus nombres.
• Qué transiciones están permitidas.
• Quién puede realizar cada cambio.
• Qué ocurre con pagos, inventario y notificaciones.
• Cómo se migran los pedidos ya almacenados.

El modelo puede completar esos vacíos con una solución habitual. Esa solución puede ser razonable y, al mismo tiempo, incompatible con el negocio real.

9.4 El conocimiento no siempre está actualizado

Un modelo fue entrenado con información recopilada antes de ser utilizado. Aunque algunas aplicaciones pueden consultar documentación o internet, el conocimiento interno no se actualiza automáticamente cada vez que cambia una biblioteca.

Esto puede producir recomendaciones basadas en:

• Versiones anteriores de un lenguaje o framework.
• Funciones que cambiaron de nombre o fueron eliminadas.
• Opciones de configuración que ya no son recomendadas.
• Ejemplos compatibles con otra versión de la dependencia.
• Prácticas de seguridad superadas.

La documentación oficial, el archivo de dependencias y la ejecución local permiten ubicar la propuesta en el presente del proyecto. Si la versión es importante, debe indicarse o comprobarse.

9.5 La ventana de contexto es limitada

El contexto es la información disponible para producir la respuesta actual: instrucciones, mensajes, fragmentos de código, archivos y resultados de herramientas. Existe un límite para la cantidad de información que puede procesarse en una interacción.

En un proyecto grande no todo entra al mismo tiempo. La herramienta debe seleccionar qué archivos incluir, resumir partes anteriores o recuperar información cuando resulta necesaria.

Una gran capacidad de contexto mejora la cobertura, pero no asegura que toda la información sea relevante ni que cada detalle reciba la misma atención.

9.6 Las instrucciones ambiguas producen supuestos

El lenguaje natural permite pedir cambios de manera cómoda, pero muchas expresiones admiten interpretaciones diferentes. “Hacé la página más moderna” no define colores, tipografía, distribución, accesibilidad ni dispositivos de destino.

Incluso una instrucción aparentemente técnica puede estar incompleta:

¿Cuántos productos existen? ¿Qué tiempo se considera aceptable? ¿La búsqueda ocurre en el navegador o en un servidor? ¿Debe tolerar errores de escritura? Sin esas respuestas, la IA elegirá una interpretación.

Los criterios observables reducen la ambigüedad: “la búsqueda debe devolver los primeros veinte resultados en menos de 300 milisegundos con cien mil productos de prueba” permite evaluar la propuesta.

9.7 Visibilidad parcial del proyecto

Una modificación puede depender de información distribuida en código, configuración, base de datos, servicios externos y decisiones que solo conoce el equipo. Leer el archivo abierto rara vez ofrece una visión completa.

La IA puede no detectar:

• Una regla definida en otro módulo.
• Una prueba que documenta un caso especial.
• Un contrato con una API externa.
• Una migración pendiente de la base de datos.
• Una convención acordada pero no documentada.
• Un uso del código que ocurre fuera del repositorio.

Antes de modificar una función compartida conviene buscar sus usos, revisar las pruebas relacionadas y comprender qué componentes dependen de ella.

9.8 Los errores se acumulan en tareas largas

Una tarea autónoma puede incluir análisis, planificación, edición, instalación, ejecución y corrección. Cada paso utiliza resultados de los anteriores. Si una decisión inicial es equivocada, las etapas siguientes pueden construir una solución coherente sobre una base incorrecta.

Supongamos que la IA interpreta que una aplicación utiliza una base de datos determinada. Puede generar el modelo, instalar el controlador, escribir consultas y crear pruebas para esa elección. El trabajo parece consistente, pero no resuelve el proyecto real.

Dividir el trabajo permite comprobar puntos intermedios:

1. Confirmar el comportamiento esperado.
2. Localizar los archivos y dependencias afectados.
3. Implementar el cambio mínimo.
4. Ejecutar pruebas relevantes.
5. Revisar el resultado antes de ampliar el alcance.

9.9 La respuesta puede variar

La generación de los modelos no es necesariamente determinista. Dos solicitudes iguales pueden producir nombres, estructuras o estrategias diferentes. Una nueva conversación también puede carecer de decisiones tomadas en una sesión anterior.

Esta variación es útil para explorar alternativas, pero puede dificultar la consistencia de un proyecto. Si cada formulario se genera con una convención distinta, el código se vuelve más difícil de mantener.

Las reglas escritas ayudan a estabilizar el resultado:

• Guía de estilo y formato.
• Estructura esperada de carpetas.
• Bibliotecas permitidas.
• Ejemplos de componentes existentes.
• Comandos de validación obligatorios.

La consistencia final debe provenir del proyecto y sus controles, no de esperar que el modelo repita siempre la misma solución.

9.10 Entornos y dependencias introducen diferencias

El código puede ser correcto en términos generales y fallar en el entorno concreto. Versiones de lenguaje, sistema operativo, permisos, variables de configuración y servicios disponibles cambian el comportamiento.

Entre los problemas habituales aparecen:

• Comandos válidos en un sistema operativo pero no en otro.
• Dependencias incompatibles entre sí.
• Rutas o nombres de archivo con diferencias de mayúsculas.
• Variables de entorno ausentes.
• Servicios externos inaccesibles durante una prueba.
• Funciones disponibles solo en versiones recientes.

Indicar el entorno reduce errores, pero la comprobación decisiva sigue siendo instalar, ejecutar y probar en condiciones equivalentes a las reales.

9.11 La IA no define por sí sola qué significa “correcto”

Que un programa compile o muestre una pantalla es apenas una parte de la corrección. También debe cumplir requisitos, manejar errores, proteger datos, responder con tiempos aceptables y ser comprensible para quienes lo mantendrán.

Una IA puede ejecutar pruebas existentes, pero esas pruebas podrían ser incompletas. También puede generar nuevas pruebas que reproduzcan sus propios supuestos y, por lo tanto, confirmar una interpretación equivocada.

9.12 Seguridad, privacidad y datos sensibles

Para recibir ayuda, una herramienta necesita contexto. Ese contexto puede contener código privado, credenciales, datos personales, registros de clientes o detalles de infraestructura.

Antes de compartir información debemos conocer las políticas de la organización y las condiciones del servicio. No se deben incluir secretos en una conversación ni copiar datos reales cuando un ejemplo anonimizado resulta suficiente.

El código generado también requiere revisión de seguridad. Un modelo puede proponer:

• Validaciones insuficientes.
• Permisos demasiado amplios.
• Consultas construidas de forma insegura.
• Datos sensibles incluidos en registros.
• Dependencias innecesarias o vulnerables.
• Claves escritas directamente en el código.

9.13 Rendimiento y mantenimiento no son visibles de inmediato

Una solución breve puede funcionar con diez elementos y volverse lenta con cien mil. También puede resolver el caso actual mediante código difícil de extender o duplicar una lógica que debería estar centralizada.

Los modelos suelen favorecer patrones frecuentes y respuestas directas. Para evaluar una implementación real debemos considerar:

• Volumen esperado de datos y usuarios.
• Consumo de memoria, red y procesamiento.
• Claridad de nombres y responsabilidades.
• Duplicación de lógica.
• Compatibilidad con la arquitectura existente.
• Costo de probar y modificar la solución en el futuro.

Las mediciones, revisiones de código y pruebas con datos representativos convierten impresiones de calidad en evidencia.

9.14 Limitación y respuesta adecuada

Cada limitación sugiere una forma concreta de trabajo. No todas se resuelven escribiendo una solicitud más extensa.

9.15 Trabajar dentro de los límites

Un flujo responsable no intenta eliminar toda incertidumbre antes de empezar. La vuelve visible y la reduce mediante ciclos cortos de trabajo.

1. Definir un resultado concreto y observable.
2. Indicar tecnología, versiones, restricciones y archivos relevantes.
3. Pedir que la IA explique los supuestos que necesita realizar.
4. Revisar el plan antes de autorizar cambios amplios.
5. Inspeccionar las diferencias producidas.
6. Ejecutar pruebas automáticas y comprobar manualmente el comportamiento.
7. Comparar el resultado con los criterios de aceptación.
8. Registrar decisiones importantes en el proyecto.

La supervisión debe aumentar con el riesgo. Una página descartable admite más experimentación que una migración de datos, un sistema de pagos o un cambio relacionado con seguridad.

9.16 Actividad de comprensión

Imaginá que solicitamos a una IA: “agregá inicio de sesión a mi aplicación y dejalo listo para publicar”. Analizá la frase sin intentar todavía implementar el cambio.

1. Identificá al menos ocho requisitos o decisiones que no fueron especificados.
2. Indicá qué archivos y datos del proyecto necesitaría conocer la herramienta.
3. Separá qué información puede inferirse, cuál debe consultarse y cuál debe verificarse mediante ejecución.
4. Enumerá los riesgos de seguridad y privacidad que requieren revisión especializada.
5. Dividí el trabajo en entregas pequeñas con una comprobación para cada una.

Finalmente, redactá una solicitud mejorada para la primera entrega. Debe incluir un objetivo limitado, el contexto técnico necesario y criterios que permitan decidir si el resultado es correcto.