Adopta los tres reflejos del profesional (contrastar con la documentación oficial, probarlo tú mismo, cazar señales de alucinación) antes de integrar nada.
Abrir esta lección en KodokonUna alucinación no es una respuesta absurda: es una respuesta plausible y errónea: un método que debería existir pero no existe, una opción renombrada hace dos versiones, un comportamiento por defecto dado la vuelta. Eso es justo lo que vuelve vulnerables a los desarrolladores competentes: el código alucinado es idiomático, está bien nombrado, es coherente con el ecosistema. Parece correcto. Tres reflejos innegociables antes de integrar nada: contrastar con la documentación oficial de la versión que usas, probar el código tú mismo en un contexto mínimo, y hacer auditar la respuesta, incluso por el propio modelo.
Toma tu respuesta anterior y audítala como si viniera de otra persona.
1. Enumera cada afirmación técnica verificable: nombre de API o de función, comportamiento descrito, valor por defecto, número de versión.
2. Para cada una, indica tu nivel de confianza: seguro / probable / por verificar.
3. Para cada "por verificar", di exactamente qué buscar en la documentación oficial: el nombre de la página, la función o el módulo en cuestión.
4. Señala todo lo que pueda depender de la versión o la plataforma, precisando desde qué versión se cumple si lo sabes.
Sé más duro contigo mismo de lo que yo lo sería: una afirmación sobrevalorada como "segura" me cuesta más que una infravalorada.Esta autoauditoría no prueba nada (un modelo puede estar seguro y equivocado) pero convierte la prosa fluida en una lista de hechos verificables, cada uno con su punto de entrada a la documentación. Eres tú quien verifica; la IA solo preparó el terreno. Aprende también a detectar las señales de alarma: una API recortada exactamente a la medida de tu necesidad (demasiado buena para ser verdad), una mezcla de convenciones de distintas versiones en el mismo fragmento, una confianza perfectamente uniforme (la experiencia real dice "depende"; la alucinación nunca lo hace) y la ausencia de toda mención a un límite o un caso límite. Ninguna señal por sí sola es prueba, pero cada una debería disparar una verificación.
Acabas de afirmar que [afirmación precisa por verificar].
1. Ayúdame a diseñar la prueba más corta posible para verificarlo yo mismo: el archivo mínimo que crear, el comando exacto que ejecutar, el resultado preciso que debería observar si tienes razón, y qué observaré en cambio si te equivocas.
2. Luego haz de abogado del diablo: ¿en qué casos sería falsa tu afirmación? Versión, plataforma, configuración, modo estricto o no, repásalo todo.
Ejecutaré la prueba yo mismo: no me pidas que te crea sin más, dame los medios para contradecirte.Este prompt aplica un principio científico al trabajo diario: una afirmación vale algo si es falsable, si sabes qué observarías en caso de que resultara falsa. Diez líneas en un archivo desechable y una ejecución valen más que cualquier nivel de confianza declarado. Para contrastar la documentación, tres hábitos: verifica en la documentación de tu versión (los modelos mezclan alegremente eras de una API), consulta el changelog cuando un comportamiento parezca haber cambiado, y ten siempre abierto un REPL o un archivo de pruebas: el coste de verificar debería ser tan bajo que nunca tengas excusa para saltarte el paso.