Diagnostica un prompt que invita a generar código inseguro

2026. Identidad de la lección

Módulo

5.2 — Ingeniería de prompts para código

Lección

Diagnostica un prompt que invita a generar código inseguro

Tipo académico

Laboratorio de depuración

Tipo de esquema

práctica

Orden

2

Tiempo estimado

25–35 minutos

En este laboratorio de depuración examinarás un prompt antes de que se genere código. Localizarás ambigüedades, alcance oculto y validación ausente; después revisarás la solicitud para reducir los supuestos inseguros de un compañero de programación con IA.

2027. Objetivo de aprendizaje

Al terminar esta lección, podrás revisar un prompt de código arriesgado y explicar cómo cada modificación reduce la ambigüedad, limita el alcance o añade protecciones verificables.

2028. Por qué importa

Un prompt puede invitar a generar código inseguro sin pedir explícitamente un comportamiento dañino. Peticiones vagas como “hazlo seguro”, “confía en el servidor” o “cubre todos los casos límite” dejan decisiones importantes sin definir. Un compañero de programación con IA puede completar esos vacíos con supuestos difíciles de detectar en un diff extenso. Diagnosticar el prompt primero lleva parte de la revisión de seguridad al punto más temprano y económico: antes de implementar.

2029. Conocimientos previos

Debes haber completado 5.2 L1 — Escribe un prompt como contrato de implementación. Debes poder distinguir contexto, alcance, restricciones, criterios de aceptación y formato de salida. También debes saber inspeccionar un cambio propuesto, compararlo con un checkpoint de Git e identificar si la petición cruza límites entre sistemas.

2030. Concepto central

El concepto central son los modos de fallo de un prompt. Un prompt arriesgado suele fallar de tres maneras:

1. Ambigüedad: un término o comportamiento admite varias interpretaciones razonables. Algunos ejemplos son “cerca”, “válido”, “seguro”, “instantáneo” y “todos los jugadores”.
2. Alcance oculto: la petición combina silenciosamente varios cambios o autoriza modificaciones fuera de la función nombrada. Pedir que se “corrijan todos los problemas relacionados” puede implicar cambios en inventario, guardado, economía, red e interfaz sin establecer sus límites.
3. Validación ausente: se solicita una implementación, pero no se explica cómo comprobar la corrección, los rechazos, las regresiones o el comportamiento que debe permanecer intacto.

Estos fallos están relacionados, pero no son intercambiables. Aclarar un término no limita el alcance, y limitar el alcance no demuestra que el resultado funcione. Un prompt seguro aborda cada fallo de forma explícita.

2031. Modelo mental

Usa el diagnóstico A-A-V:

Un prompt no está listo para implementar hasta que cada frase importante tenga una interpretación definida, cada cambio autorizado tenga un límite y cada comportamiento requerido tenga evidencia.

2032. Ejemplo concreto

Considera este prompt arriesgado:

Haz seguro el sistema de intercambio. Los jugadores no deberían poder duplicar objetos ni darse dinero gratis. Corrige cualquier problema relacionado, actualiza la interfaz si hace falta y haz que funcione en multijugador. Usa el enfoque más sencillo y cambia los archivos que sean necesarios.

La petición señala una preocupación legítima, pero deja varios supuestos peligrosos:

• Ambigüedad: no define qué operación de intercambio se aborda, qué significa “seguro” ni qué autoridad decide si una transacción es válida.
• Alcance oculto: “cualquier problema relacionado”, los cambios de interfaz y el multijugador podrían autorizar una reescritura amplia de varios sistemas.
• Validación ausente: no hay un caso reproducible de duplicación, criterios de rechazo, invariantes de la transacción ni informe de verificación.

Una revisión más segura sería:

Contexto: El flujo actual de confirmación de intercambio transfiere un objeto y una cantidad de moneda concretos entre dos jugadores. El servicio de intercambio del servidor y su registro de transacciones son la fuente de verdad para determinar si una transacción es válida y está completa; inspecciona la ruta actual de validación y confirmación antes de proponer cambios.

Alcance: Impide que un intercambio confirmado registre más de una vez la misma transferencia de objeto o moneda. Modifica únicamente la ruta de validación y confirmación de la transacción.

Objetivos excluidos: No rediseñes el intercambio, la presentación del inventario, las reglas de moneda, el emparejamiento, la persistencia ni el transporte de red. No cambies la interfaz salvo que la interfaz actual permita confirmar dos veces la misma transacción. Las garantías generales sobre entrega de mensajes, duración de los reintentos y persistencia quedan fuera de este ejemplo.

Restricciones: Conserva la API actual de intercambio y el flujo visible para el jugador. La primera confirmación aceptada para un identificador de transacción debe aplicar todos los datos validados o no producir ningún cambio de inventario ni moneda. Una confirmación posterior del mismo identificador completado no debe producir cambios adicionales; rechaza los identificadores obsoletos o desconocidos según la política existente. Mantén separadas la validación, la ejecución de la transacción y la presentación.

Criterios de aceptación:

1. Repetir la misma confirmación no puede crear una segunda transferencia de objeto o moneda.
2. Una confirmación obsoleta se rechaza sin cambiar el inventario ni la moneda de ninguno de los jugadores.
3. La primera confirmación válida ejecuta el intercambio completo, y las confirmaciones repetidas con el mismo identificador de transacción no producen cambios adicionales.
4. Las operaciones de inventario que no pertenecen al intercambio permanecen sin cambios.
5. La respuesta identifica los archivos modificados, los supuestos, las pruebas o comprobaciones manuales realizadas y los casos que no se verificaron.

Formato de salida: Antes de editar, reformula el alcance, enumera los archivos y símbolos que inspeccionarás e identifica los supuestos pendientes. Después de editar, informa del diff, de la ruta de validación, de los casos de rechazo comprobados y de cualquier evidencia de que se modificó un objetivo excluido.

La revisión no garantiza que el código sea correcto. Hace que los supuestos incorrectos sean más fáciles de descubrir y que la expansión insegura del alcance sea más fácil de rechazar.

2033. Flujo de trabajo con IA

Usa esta secuencia como diagnóstico previo a la implementación:

1. Extrae el resultado solicitado. Escribe el comportamiento mínimo que debe cambiar.
2. Marca los términos ambiguos. Señala palabras sin un límite medible, como “seguro”, “cerca”, “correctamente” o “todo”. Sustituye cada una por un estado, actor, condición o resultado observable.
3. Mapea el alcance oculto. Enumera cada sistema que el prompt podría autorizar. Conserva solo lo necesario para el resultado y convierte el resto en objetivos excluidos o preguntas abiertas.
4. Añade restricciones de seguridad y separación. Declara qué debe permanecer sin cambios y qué responsabilidades deben seguir separadas. No pidas a la IA que elija la arquitectura solo porque puede producir un parche que parece funcionar.
5. Añade validación para aceptación y rechazo. Incluye el caso normal, los datos inválidos u obsoletos, la repetición cuando corresponda y un límite de regresión.
6. Pide un diagnóstico antes de implementar. Exige ambigüedades, alcance inferido, supuestos, archivos propuestos y plan de validación. No autorices código hasta estar de acuerdo con ese diagnóstico.
7. Usa el checkpoint de Git y el diff como evidencia. Compara el cambio final con el estado previo. Un diff limpio no sustituye la validación de comportamiento, y una prueba aprobada no autoriza modificaciones fuera del alcance.

La IA puede detectar un caso que falta, pero no debe convertirlo silenciosamente en permiso para ampliar el cambio. Resuelve la decisión en el prompt o déjala explícitamente pendiente.

2034. Error común

El error común es tratar la palabra “seguro” como si fuera una restricción. En realidad, solo expresa una intención. Sin definir el riesgo o el fallo concreto, un compañero de programación con IA podría añadir validación en la capa equivocada, cambiar los límites de confianza, eliminar comportamiento útil o reescribir varios sistemas. Sustituye el lenguaje general de seguridad por condiciones de rechazo específicas, invariantes que deban conservarse y requisitos de evidencia.

2035. Práctica guiada

Diagnostica y revisa este prompt:

Haz seguro el sistema de guardado para que los jugadores no pierdan progreso ni exploten la carga. Gestiona los guardados corruptos, las versiones antiguas, varios dispositivos y cualquier otro caso límite. Mantenlo sencillo, mejora los mensajes de error y actualiza lo que sea necesario.

Usa este caso práctico ficticio. No deduzcas datos que no aparezcan aquí.

• Operación actual: El ejercicio se limita a la carga manual de una ranura de guardado local. SaveMenu solicita la carga, SaveLoadService lee y valida el archivo, y ProgressionService aplica el estado devuelto.
• Límite de autoridad: SaveLoadService es el único componente autorizado para decidir si los datos del archivo son válidos y pueden devolverse. ProgressionService solo puede sustituir la progresión activa después de recibir un resultado correcto. SaveMenu muestra el resultado y no debe escribir en el estado de progresión.
• Archivos conocidos: save/SaveLoadService.gd, save/SaveSchema.gd, progression/ProgressionService.gd, ui/SaveMenu.gd y tests/save_load_test.gd.
• Fallo reproducible: Parte de un archivo válido de versión 3, elimina sus últimos 20 bytes, colócalo en la ranura local y selecciona Cargar. La ruta actual devuelve datos parciales, asigna 0 al campo de moneda ausente y aplica ese estado a la sesión activa.
• Contrato de comportamiento: Una carga debe devolver un estado completo y validado o fallar sin modificar la progresión activa. Un guardado válido de versión 3 debe seguir cargándose con los mismos valores de progresión. Los datos rechazados pueden mostrar el mensaje genérico de error de carga que ya existe.
• Comportamientos que deben conservarse: No cambies el guardado, la frecuencia del autoguardado, la migración de versiones, la sincronización entre dispositivos, los campos del formato de archivo ni el texto de los mensajes de error. No traslades la validación a la interfaz ni permitas que esta modifique la progresión.
• Datos expresamente desconocidos: El caso no indica si los archivos incluyen una suma de comprobación, qué error del analizador representa un archivo truncado, cómo crean las pruebas los archivos temporales ni si debe seguir cargándose algún archivo de versión 2.

Crea un diagnóstico en dos columnas:

Después redacta un prompt revisado con estas partes:

1. Contexto y autoridad: Nombra la carga manual, el fallo reproducible del archivo truncado, la autoridad de SaveLoadService y la regla que permite a ProgressionService aplicar únicamente un resultado correcto.
2. Alcance: Limita el cambio a rechazar la carga truncada de versión 3 antes de modificar la progresión activa. No intentes resolver todos los problemas de guardado a la vez.
3. Archivos conocidos: Nombra los archivos del caso que deben inspeccionarse. Solo se puede proponer la modificación de un archivo después de comprobar que su responsabilidad es necesaria para el cambio acotado.
4. Objetivos excluidos y restricciones: Conserva todos los comportamientos indicados y mantén el límite de autoridad entre carga, progresión e interfaz.
5. Criterios de aceptación: Exige evidencia de que el archivo truncado se rechaza sin modificar el estado, de que el archivo válido de versión 3 sigue cargándose sin cambios y de que el guardado y la interfaz quedan fuera del diff.
6. Datos desconocidos: Convierte cada dato no disponible en un supuesto claramente etiquetado que deba confirmarse o en una pregunta bloqueante. No elijas una respuesta de forma implícita.
7. Formato de salida: Antes de editar, exige una reformulación del alcance, los archivos y símbolos inspeccionados, los supuestos, las preguntas bloqueantes y un plan de validación. Después de una edición autorizada, exige el diff, la evidencia de verificación y los riesgos pendientes.

La implementación no está autorizada mientras siga sin resolverse cualquier dato necesario para determinar el alcance, el comportamiento requerido, los archivos afectados o la validación. La IA puede inspeccionar los archivos nombrados para responder una pregunta bloqueante, pero debe comunicar la respuesta y esperar aprobación antes de editar.

Antes de terminar, explica cada revisión importante con este patrón: “Cambié ___ porque el texto original permitía ___; el texto revisado ahora hace que ___ sea observable o quede acotado”.

2036. Validación / evidencia

2037. Puntos clave

• La ambigüedad, el alcance oculto y la validación ausente son modos de fallo distintos.
• Palabras amplias como “seguro” expresan intención, pero no definen requisitos de implementación.
• Un prompt acotado declara tanto el cambio solicitado como los cambios no autorizados.
• La validación debe cubrir el comportamiento correcto, el rechazo o la recuperación y las regresiones relevantes.
• Pide a la IA que diagnostique los supuestos antes de permitir la implementación.
• Un prompt más seguro mejora la revisión; no traslada la responsabilidad del criterio técnico de la persona desarrolladora a la IA.

2038. Siguiente lección

Continúa con 5.3 — Orquestación con IA.

2039. Comprobación