Resumen y práctica
Puntos clave
- Da contexto antes de la tarea: indica el stack, las convenciones y las piezas existentes a reutilizar, o pega la firma real contra la que el código debe encajar.
- Define los límites: entradas, salidas y casos límite. El comportamiento interesante del software vive en sus bordes, así que invierte ahí tus palabras.
- Trabaja en pasos pequeños y verificables, y pide un plan antes del código; es mucho más barato corregir un plan que un .
- Itera sobre diffs dirigidos, no reescrituras completas, y usa ejemplos concretos (idealmente como pruebas) para fijar todo lo que las palabras dejan borroso.
- Administra la como un recurso, y di qué no hacer: las restricciones negativas explícitas mantienen el resultado ajustado.
Ponlo en práctica
Toma una petición vaga de una sola línea que normalmente escribirías ("agregar búsqueda a la lista") y reescríbela como un de ingeniero antes de enviar nada. Agrega el contexto (stack, el archivo que toca), las entradas/salidas, dos o tres casos límite, un ejemplo del resultado deseado, y una restricción negativa (qué no tocar). Envía la versión reescrita y compárala con lo que habría producido la versión perezosa. Haz esto con tres peticiones reales y la mejora se vuelve automática.
Prompt del capítulo
Context: <language + framework + version>, working in <file/module>.
We already <relevant existing pattern or library to reuse>.
Task: <one clear thing to build>.
Inputs / outputs: <types and shapes>.
Edge cases to handle: <list the ones that matter>.
Example: <one concrete input -> expected output>.
Constraints:
- No new dependencies — use <what we already have>.
- Touch only <this file>; don't refactor anything else.
- Keep existing names and signatures unchanged.
Before coding, give me a 3-4 line plan and wait for my "go".