Escribe un prompt como contrato de implementación

2012. Identidad de la lección

Módulo

5.2 — Ingeniería de prompts para código

Lección

Escribe un prompt como contrato de implementación

Tipo académico

Flujo de trabajo

Tipo de esquema

mixto

Orden

1

Tiempo estimado

30–40 minutos

Esta lección trata el prompt de código como un contrato operativo entre la persona desarrolladora y su compañero de programación con IA. El prompt debe hacer que el cambio previsto, sus límites y la evidencia de finalización puedan inspeccionarse.

2013. Objetivo de aprendizaje

Al terminar esta lección, podrás redactar un prompt completo para un cambio acotado de desarrollo de juegos, especificando su contexto, alcance, restricciones, criterios de aceptación y formato de salida requerido.

2014. Por qué importa

Un compañero de programación con IA puede producir código plausible a partir de una petición incompleta, pero lo plausible no demuestra que el cambio sea correcto. Un prompt estructurado reduce la ambigüedad antes de comenzar la implementación. También te proporciona una base para evaluar la respuesta, en lugar de juzgarla por su seguridad o extensión. En un proyecto de juego, esto evita que un cambio pequeño de una mecánica se convierta silenciosamente en un cambio de arquitectura.

2015. Conocimientos previos

Debes poder evaluar si una tarea está preparada para una implementación con IA, como se practicó en 5.1 L2 — Evalúa la preparación para la IA antes de implementar. En particular, ya debes poder identificar una tarea acotada y definir evidencia observable que demuestre que está completa. También debes conocer la terminología, los archivos, los sistemas y el comportamiento de juego relevantes para el cambio que vas a solicitar.

2016. Concepto central

Un prompt de implementación útil contiene cinco partes operativas:

1. Contexto: ¿Qué sistema, comportamiento, archivo, escena o situación de juego está involucrado?
2. Alcance: ¿Qué cambio exacto se solicita y qué queda explícitamente fuera de la tarea?
3. Restricciones: ¿Qué comportamiento existente, interfaces, estilo, dependencias o límites técnicos deben conservarse?
4. Criterios de aceptación: ¿Qué comprobaciones observables determinan que el cambio es correcto?
5. Formato de salida: ¿Qué debe devolver la IA para que el trabajo pueda revisarse con eficiencia?

Estas partes no son secciones decorativas. Juntas definen el límite de implementación y el contrato de revisión.

2017. Modelo mental

Usa el contrato C-A-R-A-S:

Un prompt está listo cuando otra persona desarrolladora puede distinguir una implementación dentro del alcance de una ampliación técnicamente interesante, pero incorrecta para esta tarea.

2018. Ejemplo concreto

Supón que el cambio acotado es añadir un indicador visual cuando el jugador puede interactuar con un objeto cercano.

Una petición débil sería:

Mejora el sistema de interacción y añade un aviso para los objetos interactuables.

Aquí no se define el comportamiento objetivo, el sistema afectado, las restricciones ni la evidencia.

Una petición con forma de contrato sería:

Contexto: El controlador del jugador ya identifica el objetivo interactuable actual. La interfaz tiene una etiqueta de texto existente que puede mostrarse u ocultarse.

Alcance: Actualiza la presentación de la interacción para mostrar el nombre del objetivo actual mientras exista un objetivo válido. Oculta la etiqueta cuando no haya un objetivo válido.

Restricciones: No cambies la detección del objetivo, la distancia de interacción, los controles, la ejecución de la interacción ni la disposición actual de la interfaz. Reutiliza la etiqueta existente en lugar de crear un sistema nuevo de interfaz.

Criterios de aceptación:

1. Un objetivo cercano válido hace visible la etiqueta.
2. La etiqueta muestra el nombre del objetivo.
3. Cuando no existe un objetivo válido, la etiqueta se oculta.
4. El comportamiento de interacción no cambia.

Formato de salida: Primero indica los archivos y símbolos que esperas inspeccionar. Después presenta un plan breve de implementación. Tras implementarlo, enumera los archivos modificados, explica cómo comprobaste cada criterio de aceptación e identifica cualquier supuesto pendiente.

El segundo prompt no pide a la IA que sea “más inteligente”. Define el trabajo y la evidencia necesaria para revisarlo.

2019. Flujo de trabajo con IA

Usa esta secuencia para preparar un prompt:

1. Elige un cambio acotado. Si la petición contiene varios resultados independientes, divídela antes de escribir el prompt.
2. Redacta las cinco partes del contrato. Hazlo antes de pedir código a la IA.
3. Crea un checkpoint de Git. Confirma que el repositorio está en la rama prevista, inspecciona el estado de trabajo y guarda o registra el estado actual antes de solicitar un cambio de implementación. Anota ese checkpoint para poder identificar qué pertenece a esta tarea.
4. Pide primero una reformulación del límite. Compárala con tu intención original.
5. Resuelve las discrepancias antes de implementar. No permitas que el agente convierta una inferencia en un requisito nuevo.
6. Conserva la separación entre sistemas. Declara qué responsabilidades, archivos, interfaces y sistemas deben seguir separados. No permitas que un cambio acotado mezcle lógica no relacionada en el sistema objetivo ni sustituya una separación existente solo porque una solución en un único archivo parezca más sencilla.
7. Solicita una salida revisable. Exige archivos modificados, supuestos, pasos de verificación y trabajo omitido.
8. Evalúa contra los criterios de aceptación. Considera la respuesta una propuesta hasta que la evidencia respalde el cambio. Compara el diff resultante con el checkpoint de Git antes de aceptarlo.

La IA puede ayudarte a descubrir contexto faltante o términos ambiguos, pero tú sigues siendo responsable de decidir el alcance y determinar si la evidencia es suficiente. El checkpoint de Git sirve como punto de comparación y recuperación; no demuestra por sí solo que la implementación sea correcta.

2020. Error común

El error común es describir el resultado deseado sin definir qué debe permanecer intacto. Por ejemplo, “haz más clara la interacción” puede llevar a la IA a cambiar la detección, los controles, la disposición de la interfaz y la retroalimentación al mismo tiempo. Un prompt no está completo solo porque nombra la función. También debe proteger el comportamiento no relacionado, conservar la separación entre responsabilidades existentes y explicar cómo se comprobará la finalización.

2021. Práctica guiada

Redacta un prompt con forma de contrato para este cambio acotado:

Cuando el jugador entre en el rango de detección de un contenedor bloqueado, muestra un mensaje de estado “Bloqueado”. El comportamiento de interacción existente debe permanecer sin cambios.

Completa estas cinco partes:

1. Contexto: Identifica los sistemas o comportamientos existentes que la IA debe inspeccionar.
2. Alcance: Explica exactamente qué debe hacer la nueva presentación.
3. Restricciones: Enumera al menos tres elementos que la IA no debe modificar. Incluye una protección que conserve la separación entre detección, ejecución de la interacción y presentación.
4. Criterios de aceptación: Escribe al menos tres comprobaciones observables. Incluye el caso positivo y el caso en el que el mensaje no debe aparecer.
5. Formato de salida: Especifica qué debe informar la IA antes y después de implementar.

Antes de pedir la implementación, inspecciona el estado de trabajo de Git y crea un checkpoint del estado actual. Después del ejercicio, describe cómo compararías el cambio propuesto con ese checkpoint y cómo recuperarías el estado anterior si se modificaran archivos o responsabilidades no relacionados.

Toma una decisión deliberada sobre la ambigüedad: decide si el mensaje debe aparecer para cualquier contenedor bloqueado o solo para el objetivo de interacción seleccionado en ese momento. Declara esa decisión en el prompt; no la dejes para que la IA la adivine.

2022. Validación / evidencia

2023. Puntos clave

• Un prompt de código es un contrato de implementación, no un deseo general de funcionalidad.
• Contexto, alcance, restricciones, criterios de aceptación y formato de salida cumplen funciones distintas.
• Los objetivos explícitamente excluidos y las protecciones de separación evitan que un cambio acotado se extienda hacia trabajo no relacionado.
• Un checkpoint de Git hace que el conjunto de cambios sea inspeccionable y proporciona una referencia de recuperación.
• Los criterios de aceptación deben describir evidencia observable, no intención ni confianza.
• La IA puede revelar ambigüedades, pero la persona desarrolladora decide el alcance y valida el resultado.

2024. Siguiente lección

Continúa con 5.2 L2 — Diagnostica un prompt que invita a generar código inseguro.

2025. Comprobación