Analogía: instrucciones a un ingeniero del estudio
Imagina que le encargas un trabajo a un ingeniero del estudio.
Versión mala: «Hazme mejor el estudio del pórtico.» Sin alcance, sin entregables, sin unidades, sin decir qué archivo abrir ni qué no inventar. Lo que vuelve puede ser brillante… o una cosa que no pediste. Y si no fijaste criterios, no tienes forma limpia de rechazarlo.
Versión clara: «Revisa el pórtico del nivel 3 en el archivo X. Unidades en kN y m. Lista hipótesis, cargas y advertencias. No inventes resultados de motor: si faltan, pídelos. Entrega en secciones: supuestos, hechos, pendientes. Si el modelo no abre, detente y avisa.»
Eso no es un hechizo. Es una orden de trabajo. Prompt engineering, en lenguaje de oficina, es exactamente eso: diseñar las instrucciones que le das al asistente —aquí, a un «ingeniero» dentro de la empresa digital— para que el trabajo sea verificable, no solo persuasivo.
Malas instrucciones (sin claridad, sin alcance, sin entregables) producen trabajo que no querías. Buenas instrucciones no garantizan magia; garantizan que puedes auditar, rechazar y repetir.
Esta nota forma parte de la serie sobre el harness de IA para ingeniería civil. Lee junto al system prompt (dónde viven las políticas) y al rol del LLM (por qué dos corridas pueden diferir).
Escribiste «mejor» y lo pegaste al informe
Pides una memoria de cálculo «más clara». El chat responde con un texto limpio. Lo pegas al informe. Media hora después, por curiosidad, corres el mismo pedido otra vez. El tono cambió. Un supuesto se movió. Un número aparece con otra redacción —o directamente otro valor.
Escribiste «mejor» y lo trataste como procedimiento. No lo era.
La creencia que conviene romper: prompt engineering es un curso de trucos, o pedirle que «piense paso a paso» hasta que suene profesional. En oficina AEC, prompt engineering es otra cosa: diseñar instrucciones verificables —como las que le darías a cualquier persona del equipo— y probarlas antes de que toquen un entregable.
Qué es prompt engineering (sin el curso)
En la práctica, prompt engineering es escribir instrucciones para que el modelo genere de forma más consistente lo que pediste. No garantiza identidad bit a bit entre corridas. El output —la salida— es no determinista por defecto: puede variar aunque el pedido sea el mismo. Eso lo desarrolla la pieza sobre el rol del LLM.
Un buen prompt de oficina suele incluir:
- Rol acotado (qué es y qué no es).
- Delimitadores claros (qué es dato, qué es pedido, qué es ejemplo).
- Contexto mínimo necesario (no el proyecto entero «por si acaso»).
- Formato de salida (secciones, unidades, qué marcar como supuesto).
- Ejemplos de lo correcto y de lo incorrecto cuando el riesgo lo justifica.
- Criterios de rechazo: cuándo debe decir «no puedo» en vez de inventar.
Eso no es un hechizo. Es un procedimiento incompleto hasta que lo versionas y lo corres más de una vez.
Órdenes vagas vs órdenes claras
Ilustración —demo de escritorio, no caso de cliente.
Pedido A: «Escribe mejor esta memoria.»
Pedido B: mismo encargo con rol, delimitadores, lista de chequeo (hipótesis, cargas, unidades, advertencias) y la regla «no inventes resultados de motor; si faltan, pídelos».
Corres B dos veces. La segunda no coincide del todo con la primera. Eso no es un fallo de tu prompt: es la naturaleza del modelo. Por eso un prompt que funcionó una vez no es un procedimiento de oficina.
Si la segunda corrida cambia un número que pensabas «cerrado», no lo pegues. Pide evidencia de motor o trata el texto como borrador de redacción, no como cálculo.
La diferencia entre A y B no es «más tokens mágicos». Es la misma diferencia entre un correo vago y una orden de trabajo que un jefe puede revisar.
User prompt vs políticas del system
Las políticas persistentes —el system prompt / instructions / rules— dicen cómo debe comportarse el asistente siempre: rol, unidades, prohibiciones, cuándo parar. Eso es el nivel empresa.
El user prompt —el pedido— dice qué trabajo hay que hacer ahora: el pórtico de hoy, el fragmento a reescribir, los anexos.
Prompt engineering no sustituye esas políticas. Las usa. Si mezclas todo en un solo mensaje, estás diseñando una orden de trabajo que se diluye sola. Si separas políticas (system) y pedido (user), estás diseñando como en un estudio: el manual de calidad no se reescribe en cada tarea; la orden del día sí.
Harness sin prompts claros es un taller con manos y sin contrato. Prompts claros sin harness son contratos que nadie ejecuta ni verifica.
Checklist práctico de oficina
En instructions / system (persistente)
Lo que no debería cambiar en cada pórtico: rol, unidades, prohibiciones, formato base, cuándo parar. Ver system prompt.
En el pedido (user)
El entregable de hoy, los datos, el fragmento a reescribir, los anexos. Alcance explícito. Entregable explícito.
Antes de pegar al informe
- Guarda el prompt con versión (fecha + cambio).
- Córrelo al menos dos veces con el mismo input.
- Anota qué cambió: tono, estructura, supuestos, números.
- Define qué diferencias son aceptables y cuáles detienen el flujo.
- Si hay número crítico, exige tool/motor o rechaza el pegado.
- Marca supuestos frente a hechos en la salida.
- Si no puedes decir qué archivo o motor respalda un número, no lo firmes.
Ayudas de reproducibilidad en algunos APIs (seeds, snapshots) pueden reducir variedad; no convierten al chat en ETABS. Son ayudas de software, no sustituto de solver.
Acción inmediata (menos de 15 minutos)
Toma un prompt que ya uses en el estudio.
- Añade rol.
- Separa datos y pedido con delimitadores.
- Añade un ejemplo corto de salida aceptable.
- Córrelo dos veces.
- Marca qué cambió.
- No lo pegues al informe todavía.
Si no sobrevivió dos corridas con diferencias aceptables, no es procedimiento: es un borrador.
Relación con las piezas vecinas
- El system prompt responde dónde viven las reglas persistentes.
- El rol del LLM responde por qué dos corridas pueden diferir aunque el pedido sea idéntico.
- El harness responde quién ejecuta, verifica y pide firma.
Conclusión
Escribiste «mejor» y lo pegaste al informe. Esa es la escena que este artículo quiere cortar.
Un prompt que funcionó una vez no es un procedimiento. Prompt engineering en ingeniería civil es diseñar instrucciones verificables —como las que le darías a un ingeniero del estudio—, versionarlas y probarlas, sabiendo que el modelo no es determinista y que el número serio sale de un motor, no de una frase afortunada. No son trucos. Son órdenes de trabajo.
Fuentes
- OpenAI — Prompt engineering (guía oficial: instrucciones, estructura y buenas prácticas).
Evaluación y limitaciones
Trata las notas siguientes como contexto de evaluación, no como un cálculo o una revisión verificados.
Versiona prompts como encargos. Si el resultado cambia sin cambiar datos, no lo trates como cálculo reproducido.