Tecnología · July 21, 2026 · 8 min de lectura

Ingeniería de prompts para ingenieros de software: prompting como revisión de código a la inversa

Para los ingenieros, el prompting no es un truco de redacción: es diseño de sistemas más revisión de código. Especifica las restricciones, incluye las pruebas, lee la salida, detecta la llamada obsoleta. Una guía práctica con un ejemplo trabajado y cómo se evalúa.

Los ingenieros fueron los primeros profesionales en convivir con un asistente de IA cada día laboral, así que vale la pena ser precisos sobre la habilidad. No consiste en escribir un prompt ingenioso y cruzar los dedos. Los ingenieros que obtienen verdadero apalancamiento de la IA tratan el prompting como tratan cualquier interfaz: definen el contrato, las restricciones y los modos de fallo, y luego verifican lo que reciben. Esta es la entrada de ingeniería de software de nuestra serie de ingeniería de prompts por rol, y es una de las cosas más claras que revela el AI Sandbox.

El prompting es revisión de código a la inversa

La mejor práctica que se sostiene en cada estudio reciente es aburrida en la superficie: enuncia los criterios de éxito y las restricciones antes de preguntar, dale al modelo entradas estructuradas y especifica la salida exacta que quieres. La ingeniería de prompts no se convirtió en 'escribir prompts más largos', se convirtió en 'escribir especificaciones más claras'. Por eso obliga a los ingenieros a pensar como ingenieros de sistemas. Pero la parte que realmente separa a los fuertes de los débiles es lo que ocurre después de que aparece el código: leerlo con criterio y detectar el problema sutil, una llamada obsoleta, un reintento que se traga un 4xx que debería haber sacado a la superficie, un caso límite sin manejar. Eso es fluidez con la IA aplicada al código.

Un ejemplo trabajado

Pídele a un asistente un cliente de API asíncrono con lógica de reintentos. Un prompt débil es 'escribe una función para obtener un usuario con reintentos'. Uno fuerte fija el contrato, las restricciones y, de forma crucial, las pruebas que el código debe pasar. Luego el ingeniero lee el resultado, detecta que el bucle de reintentos generado hace backoff ante un 404 sobre el que debería haber lanzado una excepción, lo corrige y ejecuta la prueba para confirmarlo.

## TASK
Write an async fetchUser(id) client method in TypeScript.

## CONSTRAINTS
- Modern async/await fetch — no deprecated request libraries
- Retry on 5xx and network errors only, never on 4xx
- Exponential backoff with jitter, max 3 attempts, 5s per-attempt timeout

## TESTS IT MUST PASS
- Returns parsed JSON on 200
- Throws immediately on 404 (no retry)
- Gives up after 3 failed attempts

## OUTPUT
Code first, then one line on any assumption you made.

• Bien: restringe la petición, entrega al modelo sus pruebas, lee la salida, detecta código obsoleto o inseguro, verifica con una ejecución rápida.
• Débil: pega 'escribe un fetch con reintentos', acepta la primera función plausible y la envía con el bug del 4xx intacto.

Buenas prácticas que de verdad marcan la diferencia

• Estructura antes que longitud. Separa la petición en secciones —tarea, entradas, restricciones, formato de salida— en lugar de un único párrafo largo. La calidad del razonamiento tiende a degradarse mucho antes de que se te acabe el espacio, así que conciso y claro le gana a extenso.
• Entrégale al modelo tus pruebas. Incluye los casos que el código debe pasar, no solo los requisitos. Escribe para tu listón en vez de para uno genérico.
• Haz que muestre su razonamiento antes del código, para que una suposición equivocada sea visible antes de que estés leyendo una implementación construida sobre ella.
• Trata tu suite de pruebas como la evaluación. La salida no está lista porque parezca correcta: está lista cuando pasa.

Modos de fallo comunes

• Pegar y enviar: confiar en código de apariencia segura sin leerlo.
• Peticiones vagas: sin restricciones, sin formato de salida, así que el modelo adivina, y adivina de forma genérica.
• Sin paso de verificación: el código compila, así que debe estar bien (no lo está, de forma fiable).

Cómo lo evaluamos

No puedes medir nada de esto con un cuestionario sobre la sintaxis de los prompts, y no aprendes nada prohibiendo la IA en la entrevista. Pones al candidato en una tarea de ingeniería realista con las herramientas que usaría de verdad y observas cómo dirige, lee y corrige, que es exactamente lo que hace una evaluación con AI Sandbox, y cómo se puntúa la fluidez con la IA como un pilar. Descubre qué más cubre una sólida evaluación de ingeniero de software, por qué esta es la forma honesta de poner a prueba el trabajo en la contratación nativa de IA, o mira cómo se compone una evaluación ajustada al rol.

Los ingenieros más fuertes no piden código con sus prompts. Piden un borrador, y luego le aplican el mismo escepticismo que aplicarían a cualquier pull request, y ese escepticismo es lo que vale la pena contratar.