El chiste funciona porque ambas personas en la imagen están haciendo el mismo trabajo: intentar explicarle a una máquina qué quisieron decir, y luego descubrir que la máquina los tomó literalmente de la manera menos útil posible.
Uno lo llama debugging. El otro lo llama prompting. Ambos están mirando algo que debería funcionar y no funciona.
Después de más de doce años construyendo sitios web y enviando miles de ellos a través de Seahawk Media, no veo que la ingeniería de prompts reemplace la ingeniería de software. La veo convirtiéndose en una parte requerida de la ingeniería de software, de la misma manera que la implementación en la nube, la observabilidad y la seguridad pasaron de ser preocupaciones especializadas al trabajo cotidiano.
- La ingeniería de prompts es una habilidad de interfaz, no un reemplazo para la ingeniería de software.
- La IA en producción necesita tanto pruebas deterministas como evaluaciones probabilísticas.
- Los prompts, el contexto, las herramientas y la configuración del modelo deben estar en control de versiones junto al código.
- Si estás eligiendo qué aprender primero, aprende los fundamentos de software y agrega prompting encima.
La comparación es divertida porque ambos lados están depurando.
Un ingeniero de software escribe código, lo ejecuta, lee el error, cambia el código y lo ejecuta de nuevo. Un ingeniero de prompts escribe una instrucción, lee la salida, cambia la instrucción o el contexto e intenta de nuevo. El bucle es casi idéntico. La superficie de fallo no lo es.
El código tradicional falla ruidosamente más a menudo. Una función lanza una excepción, una prueba se pone roja, un verificador de tipos rechaza la compilación. Un modelo puede fallar mientras suena completamente tranquilo. Devuelve prosa válida, JSON válido o código que parece válido pero está equivocado de una manera que el camino feliz no expone.
Eso cambia el método de depuración. Ya no solo preguntas: "¿Qué instrucción ejecutó la computadora?" También preguntas: "¿Qué contexto inferió el modelo, qué herramientas podía ver, qué ambigüedad dejé abierta y con qué frecuencia falla esto en un conjunto representativo de entradas?"
Idea clave: Ambas disciplinas traducen intención en comportamiento de máquina. La ingeniería de software controla el sistema alrededor de ese comportamiento; la ingeniería de prompts controla una capa probabilística dentro de él.
Lo que la ingeniería de software aún posee
La ingeniería de software posee las partes que no se pueden despachar sin rigor: modelos de datos, autenticación, permisos, estado, concurrencia, reintentos, caché, flujos de pago, migraciones, rendimiento, accesibilidad, límites de seguridad, monitoreo y recuperación cuando el sistema falla a las 2 de la mañana.
Un prompt brillante no puede reparar una restricción de base de datos faltante. No puede hacer segura una acción no autorizada, impedir que dos workers reclamen el mismo trabajo o garantizar que un webhook de pago sea idempotente. Puede sugerir código para esas cosas. El sistema aún necesita un ingeniero que sepa por qué importan y cómo probar que funcionan.
Por eso la frase "el modelo escribió la aplicación" suele exigir demasiado. El modelo puede haber producido la mayoría del código visible. El producto son las decisiones invisibles alrededor de él: qué datos son confiables, dónde ocurre la validación, qué se registra, qué puede reintentarse, qué requiere aprobación humana, y qué sucede cuando una dependencia desaparece.
Eso es ingeniería. Cuanto más rápida sea la generación de código, más del trabajo se desplaza hacia esas decisiones.
Qué es realmente la ingeniería de prompts
La ingeniería de prompts se describe a menudo como encontrar las palabras correctas. Esa era una descripción razonable cuando toda la interacción era una caja de texto. Es demasiado estrecha para los sistemas agénticos actuales.
El trabajo real es diseñar el entorno de trabajo del modelo. La instrucción importa, pero también lo hacen el prompt del sistema, el contexto del repositorio, los documentos recuperados, los ejemplos, las descripciones de herramientas, los límites de permisos, el esquema de salida, la elección del modelo, el presupuesto de tokens, y el conjunto de evaluación usado para juzgar el resultado.
Un buen ingeniero de prompts no está puliendo frases mágicas. Está decidiendo qué necesita saber el modelo, qué no debe asumir, qué acciones puede tomar, y qué evidencia contará como hecho.
Eso está mucho más cerca del diseño de interfaces y del pensamiento sistémico que de la redacción. Mi flujo de trabajo Claude Code en producción funciona porque el arnes proporciona contexto, restricciones, herramientas y verificación. La frase ingeniosa es la parte menos importante.
La línea no es código versus inglés
Las personas lo enmarcan como código por un lado y lenguaje natural por el otro. La distinción más útil es el comportamiento determinista versus probabilístico.
Con el código de aplicación ordinario, la misma entrada y estado deberían producir generalmente la misma salida. Las pruebas afirman el comportamiento exacto. Con un modelo, una instrucción sensata puede producir una distribución de salidas aceptables e inaceptables. Las pruebas siguen siendo importantes, pero también necesitas evals: un conjunto fijo de tareas realistas, puntuadas repetidamente, para que puedas ver si un cambio de prompt o modelo mejoró el sistema en general o simplemente corrigió el ejemplo frente a ti.
Aquí es donde "hacer prompts es simplemente hablar con IA" se desmorona. El chat casual optimiza la respuesta actual. Los prompts de producción optimizan el comportamiento repetible en muchas respuestas.
Donde las dos disciplinas riman
| Capa | Ingeniería de software | Ingeniería de prompts |
|---|---|---|
| Fuente de verdad | Estado del repositorio y tiempo de ejecución | Instrucciones, contexto, herramientas y configuración del modelo |
| Fallo común | Excepción, estado incorrecto o regresión | Salida plausible pero incorrecta, pérdida de contexto o mal uso de herramientas |
| Unidad de cambio | Diff de código | Diff de prompt, contexto, esquema, herramienta o evaluación |
| Verificación | Pruebas unitarias, de integración y de extremo a extremo | Conjuntos de evaluación, evaluadores, verificaciones de esquema y revisión humana |
| Reproducibilidad | Dependencias fijadas e inputs conocidas | Modelo fijado, contexto capturado, rastreo de herramientas y configuración de muestreo |
| Observabilidad | Registros, métricas, errores y trazas | Instrucciones, completaciones, llamadas a herramientas, latencia, tokens y costo |
| Despliegue | Artefacto de aplicación versionado | Instrucciones versionadas y configuración de modelo con reversión |
El vocabulario cambia, pero la disciplina no. Haz la entrada explícita. Mantén los cambios pequeños. Prueba contra la realidad. Captura suficiente estado para reproducir una falla. Revierte cuando la nueva versión es peor.
Por qué "intentar de nuevo" no es un flujo de trabajo
El hábito más peligroso en ingeniería de prompts es tratar un reintento como evidencia. La segunda respuesta es mejor, así que el problema parece resuelto. No se ha aprendido nada sobre por qué falló la primera respuesta, si la mejora se repetirá, o qué variable cambió.
Un reintento útil cambia una cosa a propósito. Agrega la restricción faltante. Elimina contexto irrelevante. Ajusta el esquema de salida. Dale a la herramienta un permiso más seguro. Agrega el caso de falla al conjunto de evaluación. Luego ejecuta la misma evaluación nuevamente.
Los ingenieros de software aprendieron esto a través de años de pruebas inestables y bugs de "funciona en mi máquina". Los ingenieros de prompts están encontrando la misma lección a través de "funcionó en el chat anterior". En ambos casos, el estado no registrado es el enemigo.
Por eso prefiero un modelo manteniendo un rol definido en lugar de cinco modelos votando sobre la misma solicitud vaga. Escribí sobre eso en por qué abrir más modelos de IA puede empeorar la salida. Más intentos no reparan una tarea subespecificada.
El contexto es el nuevo runtime
Cuando el trabajo generado por IA falla, la gente a menudo culpa al modelo primero. En sesiones de codificación de producción, la pieza faltante suele ser contexto.
El agente no conocía las convenciones del repositorio. No vio la migración de la base de datos. No se le indicó que una llamada a API cambia el estado externo. Encontró un patrón antiguo y lo copió. Tuvo el archivo relevante en la primera mitad de una sesión larga, luego perdió ese detalle cuando el contexto se llenó.
Un ingeniero de prompts ve esto como un problema de contexto. Un ingeniero de software lo ve como un problema de ambiente y dependencias. El constructor combinado corrige el sistema: coloca instrucciones duraderas en el repositorio, hace que las herramientas expongan el estado correcto, requiere aprobación para acciones destructivas, y verifica el resultado contra la aplicación real.
El mejor prompt a menudo no es un prompt más largo. Es una herramienta mejor, un contexto más pequeño, o una prueba que el agente puede ejecutar sin adivinar.
El flujo de producción que combina ambos
Este es el bucle en el que confío para trabajo de software asistido por IA. Es deliberadamente menos dramático que las demostraciones.
- Escribe los criterios de aceptación antes de pedir la implementación. Define el resultado visible para el usuario, las restricciones, y qué debe permanecer sin cambios.
- Inspecciona el sistema real. Lee el código relevante, el esquema, los registros, y el estado actual. No dejes que el modelo diseñe contra un repositorio imaginario.
- Dale al modelo un contexto acotado. Incluye los archivos y reglas que importan, mantén el material no relacionado fuera, y establece dónde debe preguntar antes de actuar.
- Genera el cambio más pequeño y coherente. Los diffs más pequeños son más fáciles de razonar tanto para humanos como para modelos.
- Ejecuta verificaciones deterministas. La verificación de tipos, pruebas, linting, compilaciones, reglas de seguridad, y restricciones de base de datos aún proporcionan garantías sólidas.
- Ejecuta evaluaciones probabilísticas donde un modelo está en el producto. Prueba entradas normales, casos límite, entradas adversariales, rechazos y fallos de herramientas en muestras repetidas.
- Revisa el diff y el comportamiento. La revisión de código detecta errores de implementación. La revisión de producto detecta un cambio técnicamente correcto que resuelve el problema equivocado.
- Versiona toda la decisión. Commit del código, prompt, contrato de herramientas, casos de evaluación y configuración del modelo necesarios para reproducirlo.
Esa es la versión funcional de la ingeniería agentic. El modelo acelera la ejecución. El ingeniero mantiene la propiedad del resultado. Si quieres más detalles de implementación, mira cómo en realidad uso Claude Code en producción.
Qué busco al contratar a un constructor de IA
No contratería a alguien para un rol de IA en producción porque me muestre un prompt largo. Le pediría que me muestre un sistema que haya lanzado y que recorra conmigo un fallo.
¿Qué salió mal en el modelo? ¿Cómo lo reprodujeron? ¿Estuvo la solución en el prompt, el contexto, la herramienta, el schema o el código circundante? ¿Qué test o evaluación evita que el fallo vuelva a ocurrir? ¿Qué pasa cuando el proveedor del modelo agota el tiempo? ¿Cuál es el rollback?
Esas preguntas revelan si alguien está operando el modelo o ingenierizando un producto. Un candidato fuerte puede moverse entre ambos niveles. Puede refinar una instrucción y luego notar que la solución real es una clave de idempotencia. Puede agregar una evaluación y luego reconocer que el output nunca debería haberse confiado sin validación determinística.
Esa es la distinción que hago en la página de contratación de ingenieros de IA. El rol no es copiar y pegar prompts. Es ingeniería de software con comportamiento del modelo, uso de herramientas, evaluaciones y costo añadidos al sistema.
Dónde es suficiente el prompting puro
No todas las tareas necesitan un mecanismo de producción. El uso de prompts por sí solo es excelente cuando el trabajo es de bajo riesgo, reversible y revisado antes de que importe.
- Explorar posicionamiento, nombres, esquemas y enfoques alternativos.
- Resumir material que puedas comparar con la fuente.
- Redactar documentos internos que una persona editará.
- Crear prototipos desechables para probar si una idea merece tiempo de ingeniería.
En estos casos el prompt es una interfaz de pensamiento. Si la respuesta es pobre, la descartas. No hay estado del cliente que corromper, dinero que mover, y ninguna automatización silenciosa continuando después de cerrar la pestaña.
Donde la ingeniería de software es innegociable
El umbral cambia en el momento en que la salida afecta a otra persona o continúa sin supervisión directa.
- Autenticación, permisos, pagos, datos del cliente, y cualquier acción irreversible.
- Agentes con herramientas que pueden escribir en bases de datos, repositorios, bandejas de entrada, o servicios externos.
- Características de IA que deben cumplir con objetivos de latencia, confiabilidad, accesibilidad o costo.
- Flujos de trabajo donde una respuesta plausiblemente incorrecta puede causar daño legal, financiero, de seguridad o reputacional.
En ese punto, el prompting se convierte en un componente dentro de un sistema de ingeniería. Necesitas límites, validación, monitoreo, respaldos y una ruta de aprobación humana proporcional al riesgo.
La ingeniería de prompts es una habilidad, no el título final.
Espero que el título de ingeniero de prompts independiente importe menos que la capacidad. La habilidad es real. El límite alrededor de ella no es lo suficientemente estable para mantenerse aislado.
Los diseñadores la usarán para crear y criticar. Los especialistas en marketing la usarán para investigar y producir. Los operadores la usarán para automatizar procesos. Los ingenieros de software la usarán para planificar, codificar, probar y mantener sistemas. Las personas valiosas no serán las que custodien una bolsa de frases secretas. Serán las que comprendan su dominio lo suficientemente profundo como para dar a un modelo un contexto útil y juzgar el resultado.
Para los constructores, eso significa volverse bilingües. Necesitas la precisión para decirle a una computadora exactamente qué debe ser verdad y el criterio de ingeniería para saber cuáles verdades no se pueden delegar a un modelo de lenguaje.
El futuro no es ingeniero de software versus ingeniero de prompts. Es ingenieros de software que pueden hacer prompting, especialistas en prompting que aprenden a hacer ingeniería, y una brecha cada vez más pequeña entre los dos.
FAQ
¿Es la ingeniería de prompts un trabajo real?
Sí, pero es más fuerte como capacidad dentro de ingeniería de IA, producto, diseño, investigación u operaciones que como título de trabajo aislado. El trabajo de prompts en producción incluye diseño de contexto, contratos de herramientas, evaluaciones, esquemas de salida, límites de seguridad, observabilidad y versionado. Escribir instrucciones ingeniosas es solo una parte.
¿Los ingenieros de prompts reemplazarán a los ingenieros de software?
No. Los prompts pueden acelerar la generación de código y hacer que la creación de software sea accesible para más personas, pero los sistemas en producción aún necesitan arquitectura, seguridad, gestión de estado, pruebas, despliegue, monitoreo y recuperación. Esas responsabilidades se vuelven más importantes cuando se añade un modelo probabilístico.
¿Necesitan los ingenieros de software aprender ingeniería de prompts?
Sí. Los ingenieros que trabajan con agentes de código o que lanzan características de IA necesitan especificar tareas claramente, controlar el contexto, diseñar permisos de herramientas y evaluar salidas no determinísticas. Los prompts se están convirtiendo en parte de la interfaz de ingeniería, como escribir un buen issue, contrato de API o plan de pruebas.
¿Qué debo aprender primero: programación o ingeniería de prompts?
Aprende los fundamentos de software primero si tu objetivo es construir software en producción. Programación, estructuras de datos, bases de datos, HTTP, Git, pruebas y seguridad te dan el modelo mental necesario para juzgar código generado. Añade ingeniería de prompts y contexto como una capa de aceleración, no como sustituto de entender el sistema.
¿Cuál es la diferencia entre un ingeniero de prompts y un ingeniero de IA?
Un ingeniero de prompts se enfoca en instrucciones del modelo, contexto, herramientas y calidad de salida. Un ingeniero de IA es dueño del sistema completo en producción alrededor del modelo, incluyendo código de aplicación, datos, recuperación, permisos, evaluaciones, monitoreo, latencia, costo y despliegue. En equipos pequeños, frecuentemente una persona hace ambas.
Conviértete en la persona que puede hacer ambas
La imagen tiene razón en el remate. Ambos roles pasan buena parte del día descubriendo por qué algo que debería funcionar no funciona. La ventaja la lleva quien puede depurar ambas capas.
Aprende a escribir instrucciones precisas. Aprende a moldear el contexto. Aprende cuándo usar herramientas y cuándo eliminarlas. Luego mantén los hábitos de ingeniería que hacían que el software fuera confiable antes de que llegaran los modelos: cambios pequeños, contratos explícitos, pruebas repetibles, logs útiles, permisos cuidadosos, y responsabilidad después del despliegue.
Mejores prompts producen mejores borradores. Una mejor ingeniería convierte esos borradores en productos en los que la gente puede confiar.
Si necesitas esa disciplina combinada en una construcción en vivo, consulta el servicio de agentic engineering o contrata a un desarrollador Claude Code.