Modelos, contexto y respuestas incorrectas

Separa la capacidad de la información disponible

Un modelo de lenguaje usa patrones aprendidos y la información que recibe durante una tarea. Los modelos actuales pueden realizar razonamientos complejos y trabajo útil de desarrollo de software. También pueden producir una respuesta detallada basada en un supuesto incorrecto.

«Modelo de frontera» describe un nivel de capacidad que cambia con el tiempo. El término no demuestra que el modelo haya leído tu repositorio. Tampoco prueba que conozca las versiones de tus dependencias ni las reglas de negocio que no están escritas. El entorno de trabajo debe proporcionar esos datos.

Un agente con las herramientas adecuadas puede recuperar información. Un chat sin acceso no puede inspeccionar el repositorio. Cuando una respuesta parezca incorrecta, plantea dos preguntas. ¿Puede el modelo resolver este problema con la información correcta? ¿Ha recibido esa información?

Cambiar de modelo puede ayudar con el primer problema. Proporcionar una política ausente o comprobar una dependencia puede resolver el segundo.

Define el contexto de esta tarea

El contexto es la información disponible para la respuesta actual. Incluye instrucciones, archivos proporcionados, conversación relevante y resultados de herramientas. Cada producto selecciona y conserva esta información de forma distinta. También puede resumir contenido anterior.

No des por hecho que el modelo lee todos los archivos de una carpeta subida. Tampoco supongas que una instrucción inicial sigue disponible durante toda una sesión larga. Pide a la herramienta que identifique los archivos y las instrucciones que ha utilizado.

Más contexto no siempre mejora una respuesta. Una decisión de arquitectura vigente puede ayudar más que archivos de código sin relación con la tarea. Una guía de migración obsoleta puede causar una respuesta incorrecta porque parece una fuente autorizada.

Considera una función ficticia de configuración de cuentas. Proporciona la ruta, el middleware de autorización, el modelo de datos pertinente y una prueba existente. Añade una restricción concreta: «Un miembro puede cambiar su nombre visible. No puede cambiar su rol en la organización». El modelo ya tiene una regla explícita que debe preservar.

Comprueba las afirmaciones de una explicación

Una respuesta puede afirmar que un endpoint es seguro porque el middleware comprueba la titularidad. Verifica cada parte de esa afirmación.

1. Comprueba que el endpoint usa el middleware indicado.
2. Comprueba que el middleware verifica la titularidad, no solo la autenticación.
3. Identifica de dónde procede la identidad del usuario.
4. Ejecuta una prueba negativa como otro usuario.

Una referencia al repositorio indica dónde buscar. No demuestra que la explicación coincida con el código.

Usa el mismo método cuando se recomiende una API. El código generado puede llamar a un método que el paquete instalado no exporta. Comprueba la versión del paquete y su documentación oficial antes de sustituir dependencias. De lo contrario, un supuesto sin verificar puede provocar una migración innecesaria.

Convierte la incertidumbre en una comprobación

«Sé preciso» no es un plan de verificación. Identifica el supuesto, las pruebas necesarias y las consecuencias de un resultado incorrecto.

Por ejemplo: «No hemos verificado el aislamiento entre tenants en este endpoint. Inspecciona el manejador de solicitudes. Añade una prueba en la que un usuario de otro tenant solicite el mismo registro». La instrucción da al agente una investigación concreta y un resultado observable.

Para cuestiones de implementación, examina la versión real del sistema. Un documento puede describir el comportamiento previsto. La inspección del código y las pruebas ayudan a establecer el comportamiento actual. Si no coinciden, registra la diferencia hasta que una persona responsable la resuelva. No elijas en silencio la respuesta más conveniente.

Los responsables de equipo pueden usar este método sin leer cada cambio de código. Pregunta qué supuestos ha comprobado el equipo. Identifica cuáles siguen abiertos y quién debe resolverlos. Esta información ayuda a decidir una publicación de forma más directa que el nombre del modelo.