6.1 Introducción
Cuando escribimos “agregá un formulario” sentimos que el objetivo es evidente. Sin embargo, la solicitud no dice qué campos debe tener, dónde aparecerá, qué validaciones necesita ni qué ocurrirá al enviarlo.
Una persona que conoce el proyecto puede completar esas ideas mediante experiencia compartida. Una inteligencia artificial solo puede apoyarse en la información incluida en su contexto y en los patrones aprendidos durante su entrenamiento.
6.2 Qué recibe realmente la IA
Según la herramienta, la entrada puede reunir varias fuentes:
- La solicitud escrita por la persona.
- Los mensajes anteriores de la conversación.
- Instrucciones generales de la herramienta o del proyecto.
- Archivos seleccionados o encontrados automáticamente.
- Código visible en el editor.
- Mensajes de error y resultados de pruebas.
- Información obtenida mediante terminal, navegador u otros servicios.
El modelo construye su respuesta a partir de esta combinación. Si una fuente importante falta o está desactualizada, la interpretación puede ser incorrecta.
6.3 La solicitud como conjunto de señales
Una solicitud útil suele contener distintas clases de información, aunque no siempre estén separadas explícitamente.
| Señal | Pregunta que responde | Ejemplo |
|---|---|---|
| Objetivo | ¿Qué resultado buscamos? | Agregar recuperación de contraseña. |
| Contexto | ¿Dónde debe funcionar? | La aplicación utiliza Node.js y PostgreSQL. |
| Requisitos | ¿Qué comportamiento debe incluir? | Enviar un enlace que expire en treinta minutos. |
| Restricciones | ¿Qué no debe hacer? | No agregar nuevas dependencias. |
| Criterios | ¿Cómo comprobaremos el resultado? | El enlace solo puede usarse una vez. |
6.4 Del texto a unidades procesables
Antes de generar una respuesta, el modelo divide el texto en unidades llamadas tokens. Un token puede representar una palabra, una parte de una palabra, un signo o un fragmento de código.
El modelo relaciona esas unidades con el resto del contexto y calcula continuaciones posibles. No busca una respuesta guardada de forma literal ni ejecuta automáticamente el código para saber si funciona.
Esto ayuda a comprender dos características:
- Pequeños cambios de redacción pueden orientar una respuesta diferente.
- Una respuesta con apariencia convincente puede ser incorrecta, porque la generación y la verificación son procesos distintos.
6.5 Contexto disponible y contexto necesario
No todo el proyecto tiene la misma importancia para cada tarea. Para corregir un botón quizá necesitemos su componente, el controlador asociado y el error de consola; miles de archivos adicionales podrían distraer o consumir espacio de contexto.
| Tipo de contexto | Ejemplo | Efecto |
|---|---|---|
| Insuficiente | “No funciona el formulario”. | Obliga a adivinar causa, tecnología y comportamiento esperado. |
| Relevante | Código del formulario, error y pasos para reproducirlo. | Permite formular y comprobar hipótesis concretas. |
| Excesivo | Todo el repositorio para cambiar un texto. | Agrega ruido, demora y posibles interpretaciones laterales. |
| Contradictorio | Documentación antigua frente al código actual. | Puede orientar la solución hacia reglas obsoletas. |
Dar buen contexto no significa entregar todo. Significa proporcionar la información necesaria para decidir correctamente.
6.6 Cómo completa la IA la información ausente
Cuando una instrucción tiene vacíos, el modelo puede:
- Elegir una opción frecuente según sus patrones aprendidos.
- Inferir una convención observada en los archivos.
- Apoyarse en decisiones tomadas antes en la conversación.
- Solicitar una aclaración.
- Proponer varias alternativas.
El problema aparece cuando un supuesto queda oculto. Si pedimos “guardá los datos”, la IA podría elegir memoria temporal, almacenamiento del navegador, un archivo o una base de datos. Todas son interpretaciones posibles, pero no equivalentes.
6.7 Ambigüedad en el lenguaje natural
El lenguaje cotidiano utiliza expresiones que dependen del contexto. Palabras como “rápido”, “moderno”, “seguro”, “simple” o “mejor” no establecen una condición verificable por sí mismas.
| Solicitud ambigua | Pregunta pendiente | Versión más concreta |
|---|---|---|
| Hacé la página más rápida. | ¿Qué medición debe mejorar? | Reducí las solicitudes iniciales sin modificar el diseño. |
| Mejorá el formulario. | ¿Diseño, validación o accesibilidad? | Agregá etiquetas visibles y mensajes junto a cada campo inválido. |
| Ordená los usuarios. | ¿Por qué campo y en qué dirección? | Ordenalos alfabéticamente por apellido, de A a Z. |
| Guardá los cambios. | ¿En memoria, archivo o base de datos? | Persistí los cambios en la tabla de productos. |
6.8 Prioridad y conflictos entre instrucciones
Una herramienta puede recibir instrucciones desde varios niveles: reglas de la plataforma, configuración del proyecto, solicitud actual y contenido de archivos. Si dos indicaciones se contradicen, debe aplicar un orden de prioridad definido por el sistema.
En nuestro trabajo también podemos prevenir conflictos:
- Mantener actualizadas las instrucciones del repositorio.
- No repetir reglas con formulaciones incompatibles.
- Indicar qué requisito tiene prioridad cuando existe una tensión.
- Diferenciar información descriptiva de una orden de ejecución.
- Solicitar que informe contradicciones antes de modificar archivos.
Por ejemplo, “no agregues dependencias” entra en conflicto con “instalá una biblioteca para validar formularios”. La IA no debería resolver silenciosamente una decisión de ese tipo.
6.9 Cómo interpreta el código existente
Cuando tiene acceso al proyecto, la IA utiliza nombres, tipos, comentarios, pruebas y estructuras para inferir cómo funciona la aplicación.
Puede deducir convenciones como:
- La ubicación habitual de componentes y servicios.
- El formato utilizado para devolver errores.
- La forma de nombrar funciones y variables.
- Las bibliotecas ya adoptadas por el proyecto.
- El comportamiento esperado expresado en pruebas.
Estas deducciones son útiles, pero pueden fallar si el proyecto es inconsistente, contiene código muerto o conserva ejemplos antiguos.
6.10 Del modelo al agente
Un modelo por sí solo genera una salida. Un agente combina el modelo con herramientas y un ciclo de observación.
Por ejemplo, ante “corregí las pruebas”, un agente puede buscar los archivos, ejecutar el conjunto de pruebas, leer el error, editar una función y volver a ejecutar. Cada resultado se incorpora al contexto de la siguiente decisión.
Este ciclo mejora la capacidad de verificar, pero también amplía el impacto posible. Por eso importan los permisos y los límites estudiados en el tema anterior.
6.11 Una solicitud, varias interpretaciones
Consideremos la instrucción:
La IA todavía tendría que resolver muchas preguntas:
- ¿Los usuarios ya existen?
- ¿Se utilizará correo, nombre de usuario o un proveedor externo?
- ¿La aplicación tiene servidor y base de datos?
- ¿Cómo se mantendrá la sesión?
- ¿Qué rutas requieren autenticación?
- ¿Existen roles y permisos?
- ¿Qué debe ocurrir después de ingresar?
Si el proyecto contiene una estructura clara, puede inferir algunas respuestas. Las decisiones restantes deberían aclararse antes de implementar una función tan sensible.
6.12 Solicitud inicial y solicitud mejorada
Una versión más controlada podría ser:
Esta versión aporta estado actual, objetivo, tecnología, comportamiento, alcance negativo y un punto de control. No define cada línea, pero reduce decisiones innecesarias.
6.13 Cómo comprobar la interpretación
Antes de autorizar una tarea amplia podemos pedir una confirmación estructurada:
- “Resumí el objetivo con tus palabras”.
- “Enumerá los requisitos y restricciones detectados”.
- “Indicá qué datos faltan para comenzar”.
- “Mostrá qué archivos pensás revisar y por qué”.
- “Proponé un plan sin modificar nada todavía”.
- “Explicá cómo verificarás cada criterio de aceptación”.
La respuesta no garantiza una ejecución correcta, pero permite detectar interpretaciones equivocadas antes de que se conviertan en muchos cambios.
6.14 Por qué una misma solicitud puede dar resultados distintos
La variación puede aparecer por diferentes razones:
- El modelo o su versión cambió.
- La conversación anterior aportó otro contexto.
- La herramienta seleccionó archivos diferentes.
- El proyecto fue modificado entre una ejecución y otra.
- La generación puede elegir continuaciones alternativas.
- Una herramienta produjo resultados distintos, como un error de red o de prueba.
Por eso no conviene depender de que una frase produzca siempre exactamente el mismo código. Debemos evaluar el resultado mediante requisitos y pruebas.
6.15 Errores frecuentes al dar instrucciones
- Confundir intención con información: saber lo que queremos no significa haberlo comunicado.
- Omitir el estado actual: la IA puede reconstruir una función que ya existe.
- Usar criterios subjetivos: “mejor” no indica qué debe cambiar.
- Mezclar objetivos incompatibles: pedir máxima sencillez y muchas funciones sin priorizarlas.
- Entregar un error sin reproducción: el mensaje puede tener varias causas.
- Suponer que leyó todo: debemos confirmar qué contexto utilizó.
- No definir límites: puede modificar más partes de las necesarias.
6.16 Actividad de comprensión
Analizá la siguiente solicitud:
Escribí al menos cinco preguntas que la IA debería resolver antes de actuar. Podrían incluir:
- ¿Qué problema concreto tienen actualmente los usuarios?
- ¿Debe agregarse búsqueda, ordenamiento, paginación o filtros?
- ¿Qué cantidad de clientes se espera mostrar?
- ¿Qué columnas pueden modificarse o eliminarse?
- ¿Qué comportamiento debe tener en celulares?
- ¿Existen componentes y estilos que deben reutilizarse?
Después, reescribí la solicitud incluyendo objetivo, contexto, requisitos, restricciones y criterios que puedan probarse.