Dos años de prompt engineering para código: qué funcionó y qué dejó de funcionar

Un ingeniero que lleva dos años usando modelos de lenguaje para programar ha publicado el balance de lo que le ha servido y de lo que no. Su conclusión de partida es incómoda para el negocio de la formación: hizo dos cursos de prompt engineering, ninguno malo, y lo que sacó en claro es que la gente que lo hace bien es la que usa los modelos a diario, no la que se sentó a escuchar. Todo lo demás es una lista de ajustes concretos que, según su experiencia, sí cambiaron los resultados.

Lo que redujo el número de roturas

El cambio con más impacto no tuvo que ver con describir mejor la tarea, sino con acotarla. Al principio sus prompts contaban lo que quería construir; los fallos venían de todo lo que el modelo modificaba de camino. Ahora enumera primero los archivos y comportamientos que no debe tocar, y después explica el trabajo. Eso, dice, le bajó más que ninguna otra cosa la tasa de "funciona, pero ha roto otra cosa".

El segundo es obligar al modelo a reformular el plan antes de escribir código: un párrafo con lo que cree que se le está pidiendo. La mitad de las veces la reformulación está mal y el error se detecta antes de que exista una sola línea, en lugar de al revisar cuarenta.

El tercero es de orden. El caching de los proveedores funciona por coincidencia de prefijo, así que cualquier cosa que cambie cerca del principio invalida todo lo que viene detrás. Él tenía sus notas de trabajo arriba y el contexto estable del proyecto debajo, justo al revés. Darle la vuelta es cuestión de cinco minutos y se nota en la factura de las sesiones largas.

Trucos que ya no hacen nada

Subir el ajuste de esfuerzo al máximo por defecto no compensa. En un renombrado o en un archivo de boilerplate no aporta nada, y sostiene que hay indicios de que en algunos modelos el esfuerzo alto rinde algo peor en código que el medio. Merece la pena medirlo en las tareas propias en lugar de dar por hecho que más es mejor.

También ha descartado el "piensa paso a paso", las personas expertas asignadas al modelo y las instrucciones para que no alucine. En los modelos de razonamiento actuales no producen ningún efecto medible, y el paso a paso además añade latencia. Los ejemplos few-shot, en cambio, siguen rindiendo por encima de todo eso.

Queda un aviso que afecta a cualquier equipo que cambie de modelo: el mismo prompt no se comporta igual en dos endpoints. Él trabaja con Opus 5 y glm-5.3 en paralelo y la diferencia al seguir instrucciones es mayor de lo que esperaba. Uno toma la instrucción al pie de la letra; el otro intenta deducir qué querías decir y rellena huecos por su cuenta. Ninguno es peor, pero vienen de entrenamientos posteriores distintos, así que un prompt afinado contra uno no lo está contra el otro. Apunta de paso que los modelos chinos salen más baratos por token, algo que pesa más de lo que parece cuando se ejecutan bucles.

Nada de esto es ingenioso. Es ser específico con las restricciones y no deshacerlo después metiendo ruido alrededor.