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

Prompt engineering para ingenieros de software: una guía real

El prompt engineering para ingenieros de software es diseño de sistemas más revisión de código: especifica restricciones, incluye las pruebas, lee el resultado y detecta la llamada obsoleta.

← Parte de Evaluaciones generadas por IA: la guía completa de 2026

Los ingenieros fueron los primeros profesionales en convivir con un asistente de IA cada día laborable, por lo que vale la pena ser precisos sobre la habilidad. El prompt engineering para ingenieros de software no consiste en escribir un prompt ingenioso y esperar lo mejor. Si contratas ingenieros, el apalancamiento es real y también lo es el riesgo: un asistente ya redacta una parte significativa del código de primera pasada, y la calidad con que un ingeniero dirige e interroga ese borrador incide directamente en la calidad entregada y en la carga de revisión. Los ingenieros que obtienen valor real de la IA tratan el prompting como 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 en nuestra serie de prompt engineering por rol, y es una de las cosas más claras que el AI Sandbox pone de manifiesto.

Por qué esto es ahora una competencia central

El instinto de tratar la fluidez en codificación con IA como una moda pasajera, o como algo en lo que solo se apoyan los juniors, invierte exactamente el riesgo. Cuanto más código redacta un asistente, más se desplaza el cuello de botella de escribir a revisar, y revisar es la habilidad más difícil. Un equipo que entrega código redactado por IA sin un ingeniero que lo lea críticamente no ha ahorrado tiempo; ha trasladado el coste aguas abajo, a incidentes en producción y a la cola de revisión. Los ingenieros que vale la pena contratar son los que convierten al asistente en un multiplicador de fuerza del criterio, no en una manguera de código de apariencia plausible que nadie ha leído correctamente.

Eso reencuadra lo que estás evaluando realmente. No si alguien puede producir código con IA, que casi cualquiera ya puede, sino si el código que respaldan es el código que querrías en tu base de código. La diferencia entre esos dos ingenieros es invisible en un currículum e invisible en un test de sintaxis. Solo es visible en cómo trabajan una tarea real.

El prompting es revisión de código al revés

La buena práctica que se mantiene es aburrida en la superficie: exponer los criterios de éxito y las restricciones antes de preguntar, dar al modelo entradas estructuradas y especificar el resultado exacto que quieres. El prompt engineering no se convirtió en 'escribe prompts más largos'; se convirtió en 'escribe especificaciones más claras'. Por eso obliga a los ingenieros a pensar como ingenieros de sistemas. Pero la parte que separa al fuerte del débil es lo que ocurre después de que aparece el código: leerlo críticamente y detectar el problema sutil, una llamada obsoleta, un reintento que silencia un error 4xx que debería haber aflorado, un caso límite no manejado. Eso es AI fluency aplicada al código, y es el mismo discernimiento que un buen revisor aporta a la pull request de un colega.

La especificación carga con el trabajo

Cuando los ingenieros describen un prompt que 'simplemente funcionó', lo que suelen querer decir es que especificaron bien el problema. El modelo no lee la intención; lee el texto. Cada restricción que dejas implícita es una que el modelo rellena con un valor predeterminado genérico, y los valores predeterminados genéricos son la vía de entrada de las bibliotecas obsoletas, los tiempos de espera ausentes y los errores silenciados. Escribir la especificación no es una carga que toleras para usar la herramienta. Es el mismo trabajo de clarificación que harías antes de escribir el código tú mismo, hecho visible y reutilizable.

Los borradores pequeños y revisables ganan a los grandes

Hay una ley de escala en la revisión del resultado de la IA que los ingenieros con experiencia aprenden rápidamente: cuanto mayor es el fragmento generado, menos cuidadosamente lo lee nadie. Pide una función completa y obtienes una pared de código plausible que es genuinamente difícil de auditar, así que se hojea y se entrega. Pide una función con un contrato claro y sus pruebas, y obtienes algo lo suficientemente pequeño como para entenderlo realmente. El ingeniero fuerte, por tanto, hace prompts en unidades revisables, no porque el modelo no pueda producir más de una vez, sino porque tiene intención de leer todo lo que conserva. Acotar la solicitud es en sí mismo un acto de control de calidad, y es uno de los indicadores más fiables entre un ingeniero que dirige la herramienta y uno al que la herramienta dirige.

Un ejemplo práctico

Pide a un asistente un cliente API asíncrono con lógica de reintento. Un prompt débil es 'escribe una función para obtener un usuario con reintentos'. Uno fuerte fija el contrato, las restricciones y, crucialmente, las pruebas que el código debe superar. Luego el ingeniero lee el resultado, detecta que el bucle de reintento generado retrocede ante un 404 cuando debería lanzar 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.

• Bueno: acota la solicitud, entrega al modelo sus pruebas, lee el resultado, detecta código obsoleto o inseguro y verifica con una ejecución rápida.
• Débil: pega 'escribe un fetch con reintentos', acepta la primera función plausible y la entrega con el error de 4xx intacto.

El reflejo de revisión es la habilidad escasa

La razón por la que el error de 4xx es una buena prueba es que es invisible para quien no sabe de antemano cómo deben comportarse los reintentos. El código generado compila, supera un smoke test de ruta feliz y se parece a todos los bucles de reintento que el modelo ha visto, porque es un promedio de ellos. Detectarlo requiere un ingeniero que lee con una pregunta concreta en mente: ¿qué ocurre en las rutas de error que nadie demostró? Ese reflejo, leer buscando los modos de fallo en lugar del caso de éxito, es la misma habilidad que siempre han tenido los revisores senior. La IA no lo ha creado, pero lo ha vuelto más escaso en relación con la demanda, porque el volumen de código que necesita revisión ha aumentado mientras que la disciplina de leerlo no. Evaluar ese reflejo es ahora más valioso que evaluar la velocidad de producción bruta, que la herramienta ha commoditizado en gran medida.

Buenas prácticas que realmente marcan la diferencia

• Estructura sobre longitud. Divide la solicitud en secciones —tarea, entradas, restricciones, formato de salida— en lugar de un párrafo largo. La calidad del razonamiento tiende a degradarse mucho antes de que te quedes sin espacio, así que lo compacto y claro supera a lo extenso.
• Entrégale al modelo tus pruebas. Incluye los casos que el código debe superar, no solo los requisitos. Escribe para tu listón en lugar de uno genérico.
• Haz que muestre su razonamiento antes del código, para que un supuesto erróneo sea visible antes de que estés leyendo una implementación construida sobre él.
• Prohíbe explícitamente los modos de fallo. Nombra las bibliotecas obsoletas, los patrones no permitidos y la semántica que importa, porque el modelo recurre por defecto al promedio de todo lo que ha visto.
• Trata tu suite de pruebas como la evaluación. El resultado no está hecho porque parece correcto. Está hecho cuando supera las pruebas.

Modos de fallo comunes

• Pegar y entregar: confiar en código de apariencia segura sin leerlo, para descubrir el error en producción.
• Solicitudes vagas: sin restricciones ni formato de salida, el modelo adivina, y adivina de forma genérica.
• Sin paso de verificación: el código compila, así que debe ser correcto, lo cual no es cierto de forma fiable.
• Pedir toda la función de una vez en lugar de un borrador revisable, de modo que nada del resultado es lo suficientemente pequeño para comprobarlo realmente.

Cada uno de estos es un fallo de revisión, no un fallo de codificación. La IA no ha introducido una clase de error que no existía antes; ha hecho que los antiguos sean más rápidos de producir y más fáciles de pasar por alto porque el resultado parece tan terminado. La salvaguarda es la misma que siempre ha separado al senior del junior: la negativa a confiar en código que no has entendido, aplicada ahora al código que escribió una máquina.

Cómo se ve esto en toda la pila

El ejemplo del bucle de reintento es deliberadamente pequeño, pero la misma forma se repite en todas partes donde trabaja un ingeniero. En el frontend es el componente generado que se vuelve a renderizar en cada pulsación de tecla porque nadie restringió las dependencias del efecto. En infraestructura es el bloque de Terraform que abre un grupo de seguridad más amplio de lo previsto porque el modelo recurrió al valor predeterminado permisivo. En el código de la capa de datos es la consulta que el asistente escribió sin una sugerencia de índice, bien en los datos de semilla y un full table scan en producción. Ninguno de estos son errores exóticos; son las consecuencias ordinarias de aceptar un primer borrador plausible sin la lectura específica de dominio que los detectaría. La disciplina del prompt es universal, pero la disciplina de revisión es donde se muestra la profundidad real de un ingeniero, porque solo puedes detectar lo que entiendes.

Eso merece reflexión cuando diseñas una evaluación. Un candidato que dirige el modelo de forma impecable pero nunca nota el grupo de seguridad ampliado te está diciendo algo preciso sobre el límite de su competencia. La herramienta hace la escritura; el ingeniero aporta el criterio sobre qué es seguro conservar. Una evaluación que solo mide si apareció código funcional pierde por completo la pregunta de si el ingeniero habría detectado el fallo. Esa distinción —entre resultado producido y resultado comprendido— es la que vale la pena construir alrededor de toda la evaluación.

La AI fluency es un pilar, no un complemento

En nuestro modelo de cinco pilares, la AI fluency se sitúa junto a la capacidad cognitiva, de dominio, de juicio situacional y conductual, sin reemplazar ninguna de ellas. Para un ingeniero ese orden importa: detectar que un bucle de reintento maneja mal un 404 requiere conocer primero la semántica HTTP y el manejo de errores. La AI fluency es el discernimiento en capas sobre el criterio de ingeniería, por lo que la tratamos como AI fluency evaluada como un pilar diferenciado puntuada encima de las habilidades centrales, nunca como sustituto de ellas. Esto también actualiza el viejo debate sobre las tareas para casa frente a la codificación en vivo: la pregunta ya no es si el candidato puede escribir el código solo, sino cómo trabaja con las herramientas que usará realmente en el puesto.

Cómo lo evaluamos

No puedes medir nada de esto con un cuestionario sobre sintaxis de 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 realmente y observas cómo dirige, lee y corrige, que es exactamente lo que hace una evaluación con el AI Sandbox. Consulta qué cubre una buena evaluación de ingeniero de software, cómo difiere el rol hermano para los analistas de datos y por qué esta es la forma honesta de evaluar el puesto en la contratación AI-native.

Los ingenieros más fuertes no hacen prompts para obtener código. Hacen prompts para obtener 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.